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Abstract 

The Hindley-Milner (HM) type system allows programmers to 
write polymorphic functions and automatically infers the types at 
which those functions are used. In this type system, the inferred 
types are always unambiguous, and every expression has a principal 
type. However, type inference is sometimes unwieldy or impossible 
- especially in the presence of type system extensions such as type 
classes and non-injective type-level functions. In these scenarios, 
programmers cannot provide type arguments explicitly, as HM 
requires such types to be invisible. 

In this paper, we describe an extension to HM that allows for 
visible type application. Our extension is based on a novel type 
inference algorithm, yet a declarative presentation of the system 
can be specified via a simple extension to HM. We prove that our 
extended system is a conservative extension of HM and admits 
principal types. We then extend our approach to a higher-rank type 
system with bidirectional type-checking. We have implemented 
this system in the Glasgow Haskell Compiler and show how our 
approach scales in the presence of complex type system features. 

1. Introduction 

The Hindley-Milner (HM) type system CzHEEHEzl achieves remark¬ 
able concision. While allowing a strong typing discipline, a pro¬ 
gram written in HM need not mention a single type. The brevity of 
HM comes at a cost, however: HM programs must not mention a 
single type. While this rule has long been relaxed by allowing visi¬ 
ble type annotations (and even requiring them for various type sys¬ 
tem extensions), it remains impossible for systems based on HM, 
such as OCaml and Haskell, to use visible type application when 
calling a polymorphic function]^] 

This restriction makes sense in the HM type system, where 
visible type application is unnecessary, as all type instantiations 
can be determined via unification. Suppose the function id has type 
V a. a —>• a. If we wished to visibly instantiate the type variable 


1 Syntax elements appearing in a programmer’s source code are often called 
explicit, in contrast to implicit terms, which are inferred by the compiler. 
However, the implicit/explicit distinction is sometimes used to indicate 
whether terms are computationally significant filsl . Our work to applies 
only to the inferred vs. programmer-specified distinction, so we use visible 
to refer to syntax elements appearing in source code. 


[Copyright notice will appear here once ’preprint’ option is removed.] 
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Figure 1. The type systems studied in this paper 


a (in a version of HM extended with type annotations), we could 
write this expression 

(id :: Int —t Int) 

This annotation forces the type checker to unify the provided type 
Int —t Int with the type a —t a, concluding that type a should 
be instantiated with Int. However, this annotation is a roundabout 
way of providing information to the type checker. It would be much 
more direct if programmers could provide type arguments directly, 
writing the expression 

id @lnt 
instead. 

So why do we want visible type application? Considering a lan¬ 
guage like Haskell - as implemented by the Glasgow Haskell Com¬ 
piler (GHC) - which is based on HM but extends it significantly, 
we find two main benefits. 

Type instantiation cannot always be determined by unification. 
Some Haskell features, such as type classes f28l and GHC’s type 
families (3) |4) [lOj, do not allow the type checker to unambigu¬ 
ously determine type arguments from an annotation. The current 
workaround for this issue is the Proxy type which clutters imple¬ 
mentations and requires careful foresight by library designers. Vis¬ 
ible type application improves such code. (See Section[2]) 

It is sometimes painful to determine instantiations via type anno¬ 
tations. Even when type arguments can be determined from an 
annotation, this mechanism is still not always friendly to develop¬ 
ers. For example, the variable to instantiate could appear multiple 
times in the type, leading to a long annotation. Partial type signa¬ 
tures help (29), but they don’t completely solve the problem. Sec¬ 
tion^ also contains an example of this issue. 

Although the idea seems straightforward, adding visible type 
applications to the HM type system requires care, as we describe in 
Section^] In particular, we observe that we can allow visible type 
application only at certain types: those with specified type quantifi¬ 
cation. These types are known to the programmer via type anno¬ 
tation. Such types may be instantiated visibly. Their instantiations 
may also be inferred as usual, should the programmer omit type 
applications. 
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This paper presents a systematic study of the integration of vis¬ 
ible type application within the HM typing discipline. In particular, 
we study this new feature in the context of four novel type systems, 
summarized in Figure[l] 

Section |4] presents System HMV, a conservative extension of 
the declarative HM type system. HMV makes a distinction between 
specified and generalized type quantification and with support for 
visible type application. This extended system retains HM’s sim¬ 
plicity and compositionality, making programs with visible type 
applications easy to reason about. 

Section[5]develops System V, a novel syntax-directed type sys¬ 
tem with visible type application that faithfully implements the 
specification of the previous section. This type system directly cor¬ 
responds to a type inference algorithm, called V. We show that al¬ 
though Algorithm V works differently than Algorithm W QD, it re¬ 
tains the ability to calculate principal types. The key insight is that 
we can delay the instantiation of polymorphic variables until nec¬ 
essary. We prove that System V is sound and complete with respect 
to HMV, and that Algorithm V is sound and complete with respect 
for System V. These results show the principal types property for 
HMV. 

Our goal with this work is to extend the Glasgow Haskell Com¬ 
piler with visible type application. Doing so requires consider¬ 
ing interactions with the many type system extensions featured in 
that context. Most interactions are orthogonal, but our work has 
led us to reconsider the treatment of higher-rank polymorphism in 
GHC t23l . As with visible types, that feature is based on reasoning 
about user-specified polymorphism. 

Therefore, Section [6] extends our ideas to a bidirectional sys¬ 
tem with higher-rank types and, for full expressiveness, scoped type 
variables. This section includes a syntax-directed set of rules, called 
System SB, that adapts the design principles of System V to GHC’s 
current algorithm for higher-rank polymorphism. The section also 
includes a novel, simple, declarative specification of this bidirec¬ 
tional type system, called System B. We prove that System SB is 
sound and complete with respect to System B. 

System SB forms the basis for our implementation in the Glas¬ 
gow Haskell Compiler]^ Section [7] describes this implementation 
and elaborates on interactions between our algorithm and other fea¬ 
tures of GHC. 

Finally, Section [8] discusses related work. Additionally, Ap¬ 
pendix [G] presents a variant of Systems B and SB designed for 
comparison with the higher-rank type system of Dunfield and Kr- 
ishnaswami l9l . 

The Appendices of this paper contain extended examples and 
detailed proofs of the properties studied about each of the systems. 

However, before we discuss how to extend HM type systems 
with visible type application, we first elaborate on why we would 
like this feature in the first place. The next section briefly describes 
two situations in Haskell where visible type applications would 
benefit programmers. 


2. Examples of visible type application 

When a Haskell library author wishes to give a client the ability 
to control type variable instantiation, the current workaround is the 
standard library’s Proxy type. 

data Proxy a = Proxy 

However, as we shall see, programming with Proxy is noisy and 
painfully indirect. With built-in visible type application, these ex- 


2 Our implementation is available from https://github.com/ 
goldfirere/ghc at the popl-2016 tag. 


amples are streamlined and easier to work withNIn these examples 
and throughout this paper, unadorned code blocks are accepted by 
GHC 7.10, blocks with a solid gray bar at the left are ill-typed, and 
blocks with a gray background are accepted only by our implemen¬ 
tation of visible type application. 

2.1 Resolving type class ambiguity 

Suppose a programmer wished to normalize the representation 
of expression text by running it through a parser and then 
pretty printer. The normalize function below maps the string 
"7 - 1 * 0 + 3 / 3" to "((7 - (1 * 0)) + (3 / 3))", 
resolving precedence and making the meaning clearjj 
normalize :: String —y String 
normalize x = show ((read :: String —y Expr) x) 

However, the designer of this function can’t make it polymor¬ 
phic in a straightforward way. Adding a polymorphic type signature 
results in an ambiguous type, which GHC rightly rejects. 

normalizePoly :: V a. (Show a, Read a) =4- String —y String 
normalizePoly x = show ((read :: String -4 a) x) 

Instead, the programmer must add a Proxy argument, which is 
never evaluated, to allow clients of this polymorphic function to 
specify the parser and pretty-printer to use 
normalizeProxy :: V a. (Show a, Read a) 

=y Proxy a —» String —y String 
normalizeProxy _ x = show ((read :: String -4 a) x) 
normalizeExpr :: String —y String 

normalizeExpr = normalizeProxy (Proxy :: Proxy Expr) 
With visible type application, we can write these two functions 
more directly^] 

normalize :: V a. (Show a, Read a ) =4- String —y String 
normalize x = show (read @a x) 
normalizeExpr :: String —y String 
normalizeExpr = normalize @ Expr 

Although the show/read ambiguity is somewhat contrived in 
this case, proxies are indeed useful in more sophisticated APIs. For 
example, suppose a library design would like to allow users of the 
library to choose the representation of an internal data structure to 
best meet the needs of their application. If the type of that data 
structure is not included in the input and output types of the API, 
then a Proxy argument is a way to give this flexibility to clients^] 

2.2 Dependently-typed programming 

Our next example is an excerpt of a longer example of dependently- 
typed programming in GHC. Space constraints prevent us from 

3 Visible type application has been a GHC feature request since 2011. See 
https://ghc.haskell.org/trac/ghc/ticket/5296 

4 These examples use the following functions from the standard library 

show :: Show a = 4 - a —y String 
read :: Read a =4- String —y a 

as well as user-defined instances of the Show and Read classes for the type 

5 Our new extension TypeApplications implies the extension 
AllowAmbiguousTypes, which allows our updated normalize defi¬ 
nition to be accepted. 

6 See http://stackoverflow.com/questions/27044209/ 

haskell-why-use-proxy 
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fully explaining the code here: more details about this example are 
available in Appendix [A] This code is inspired by examples from 
McBride’s ICFP 2012 keynote fl5l . 

GHC supports dependently-typed programming through two 
main features: type-level computation and indexed types. For the 
former, type families GD0CRD and data type promotion 1301 allow 
programmers to write functions using datatypes, such as booleans 
and lists, at the type level. For the latter, generalized algebraic 
datatypes (GADTs) i22l allow type arguments to be non-uniform. 
For example, the equality GADT, defined below, is inhabited by 
Ref! only when its two arguments are equal. 

data a :~: b where 
Ref !:: a :~: a 

We can use these features in the following function that asserts 
an equality fact about type-level computation: We can commute a 
type family if with list cons (:). Note that fact takes two Proxy 
arguments; the type variables t and f appear only in arguments to 
the If type family and thus cannot be solved via unification. 

type family If cond t f where 
If ’ True tf = t 
If ’ False t f = f 

fact :: V t f s b. Sing b -A Proxy t -A Proxy f -A 
((If btf ) ’: s) :~: (If b (t ’: s) (f ’: s)) 

This fact is needed in the code below, which comes from a 
simple compiler from a boolean expression language to a stack 
machine. We use this fact when compiling conditional expressions, 
as shown below. (Again, more details are in the appendix.) Not only 
do we need to provide proxies when calling fact, but we must also 
provide a (long) type annotation for its return type. Because the 
result of fact is used as the scrutinee of a GADT pattern-match, 
GHC cannot use unification to resolve the type variable s in this 
type. Instead, the only way to supply s is through this annotation. 

compile (SCond (seO :: Sing eO) 

(sel :: Sing el) (se2 :: Sing e2 )) = 
case (fact (sEval seO) 

(Proxy :: Proxy (Eval el)) 

(Proxy :: Proxy (Eval e2)) :: 

((If (Eval eO) (Eval el) (Eval e2)) ’: s) 

(If (Eval eO) ((Eval el) ’: s) ((Eval e2) ’: s))) of 
Refl —>■ compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

This situation could be slightly improved by adding a Proxy for s 
to fact. However, s appears outside of If in the type of fact, so 
the programmer may not be aware of the issue when writing fact’s 
type. 

In the presence of visible type application, we avoid the proxies 
altogether 

fact :: V t f s b. Sing b -A 

((If b t f)s) :~: (If b (t s) (f s)) 

and provide the type arguments directly, without annotation 

compile (SCond seO (sel :: Sing el) (se2 :: Sing e2)) = 
case fact @(Eval el) @(Eval e2) @s (sEval seO) of 
Refl —> compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

Summary In these cases, although Proxy solves the problem, the 
mechanism clutters code and requires library authors to design their 
functions to take Proxy arguments. Furthermore, once a library 


Why specified polytypes? 

It may seem possible to characterize how GHC quantifies 
type variables, in an attempt to define some sort of “canon¬ 
ical quantification” as a part of the type inference process. 
We could then prefer one version of the principal type of 
an expression over another, allowing us to predictably visi¬ 
bly instantiate type variables. However, various type system 
features mean that such a characterization would be terribly 
complicated. In particular: 

Class constraints don’t have a fixed ordering in types, and 
it is possible that a type variable is mentioned only in a 
constraint. Which of the following is preferred? 

V r m w a. (MonadReader r m 

, MonadWriter w m) =y a -A m a 

V w m r a. (MonadWriter w m 

, MonadReader r m) =>■ a -A m a 

Equality constraints and GADTs can add new quantified 
variables. Should we prefer the type V a. a A a or the 
equivalent type V a b. (a ~ b) =A- a -A bl 
Type abbreviations mean that quantifying variables as they 
appear in order in the term can be ambiguous without also 
specifying how type abbreviations are used and when they 
are expanded. Suppose 
type Phantom a = Int 
type Swap a b = (b, a) 

Should we prefer V a b. Swap a b —t Int or 

V b a. Swap a b -A Inti Similarly, should we prefer 

V a. Phantom a -A Int or Int -A Inti 

Type families also disturb variable ordering. Suppose 
type family Swap (a :: *) :: * 
type instance Swap (a, b) = (b, a) 

Should we prefer V a b. Swap (a, b) -A Int or 

V b a. Swap (a, b) -A Inti This issue is harder to 
solve than the difficulty with vanilla type synonyms, as 
type families may or may not be able to reduce. 


author has specified that a function should take a Proxy argument, 
then it must always be called with a proxy. 

In contrast, visible type application requires little planning from 
library designers, can be used with less clutter, and need not be used 
at all in situations where unification can already determine the type 
argument. 

These examples are not the only ones that we have seen. Haskell 
programmers make frequent use of Proxy. Appendix|A|contains an 
additional longer example of the benefit of visible type application. 

3. Our approach to visible type application 

Visible type application seems like a straightforward extension, but 
adding this feature - both to GHC and to the HM type system that 
it is based on - turned out to be more difficult and interesting than 
we first anticipated. In particular, we encountered two significant 
problems when trying to extend the HM type system with visible 
type application. 

3.1 Just what are the type parameters? 
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The first problem is that it is not always clear what the type 
parameters to a polymorphic function are! 

One aspect of the HM type system is that it permits expressions 
to be assigned any number of isomorphic types. For example, the 
identity function for pairs 

pid (x,y) = (x, y) 

can be assigned any of the following types 

(1) Vab. (a,b)->(a,b) 

(2) Vafc. (b, a) —►(*, a) 

(3) V c a b. (a, b) -A (a, b) 

All of these types are principal; no type above is more general than 
any other. However, the type of the expression 
id @tnt @Bool 

is very different depending on which “equivalent” type is chosen 
for pid 

( Int, Bool) -A ( Int, Bool) — pid has type (1) 

(Bool, Int) —>■ (Bool, Int) - pid has type (2) 

V b. (Bool, b) —>■ (Bool, b) - pid has type (3) 

Of course, there are ad hoc mechanisms for resolving this am¬ 
biguity. We could try to designate one of the above types (1-3) as 
the real principal type for id, perhaps by disallowing the quantifi¬ 
cation of unused variables (ruling out type 3 above) or by enforcing 
an ordering on how variables are quantified (preferring type 1 over 
type 2 above). Our goal would be to make sure that each expres¬ 
sion has a unique principal type, with respect to its quantified type 
variables. However, in the context of the full Haskell language, this 
strategy fails. There are just too many ways that types that are not 
a-equivalent can be considered equivalent by HM. (See the box on 
the preceding page for a summary.) 

In the end, although it may be possible to resolve all of these 
ambiguities, we prefer not to. That approach leads to a system 
that is fragile (a new extension could break the requirement that 
principal types are unique up to a-equivalence), difficult to explain 
to programmers (who must be able to determine which type is 
principal) and difficult to reason about. 

Our solution: specified polytypes Therefore, our system is de¬ 
signed around the following principle: 

Only “specified” type parameters can be instantiated via 
explicit type applications. 

In other words, we allow visible type application to instantiate a 
polytype only when both of the following are true: 

1. The polytype is already fixed: constraint solving will give us no 
more information about the type. 

2. The programmer may reasonably know what the type is. 

In practice, these guidelines mean that visible type application 
is available only on types that are given by an annotation. These 
restrictions follow in a long line of work requiring more user 
annotations to support more advanced type system features [13] 
|22][23]. See Section|7]for discussion on how our implementation in 
GHC works with our design principle. 

3.2 What is the specification of the type system? 

We don’t want to extend just the type inference algorithm that GHC 
uses. We would also like to extend its specification, which is rooted 
in HM. This way, we will have a concise description (and better 
understanding) of what programs type check, and a simple way to 
reason about the properties of the type system. 


Our first attempt to add type application to GHC was based on 
our understanding of Algorithm W, the standard algorithm for HM 
type inference. This algorithm instantiates polymorphic functions 
only at occurrences of variables. So, it seems that the only new form 
we need to allow is a visible type right after variable occurrences 
x @n ... @r n 

However, this extension is not very robust to code refactoring. 
For example, it is not closed under substitution. If type applica¬ 
tion is only allowed at variables, then we can’t substitute for this 
variable and expect the code to still type check. Therefore our al¬ 
gorithm should allow visible type applications at other expression 
forms. But where else makes sense? 

One place that seems sensible to allow a type instantiation is 
after a polymorphic type annotation (such an annotation certainly 
specifies the type of the expression) 

(Ax ->x::Vai. (a, b) -A (a, b)) @lnt 
Likewise, if we refactor this term as below, we should also allow a 
visible instantiation after a leQ 

(let y = ((Ax Ax)::Vaii. (a, b) -A (a, b)) in y) @lnt 
However, how do we know that we have identified all sites 
where visible type applications should be allowed? Furthermore, 
we may have identified them all for core HM, but what happens 
when we go to the full language of GHC, which includes features 
that may expose new potential sites? 

One way to think about this issue in a principled way is to 
develop a compositional specification of the type system, which 
allows type application for any expression that can be assigned a 
polytype. Then, if we develop an algorithm that is complete with 
respect to this specification, we will know that we have allowed 
type applications in all of the appropriate places. 

Our solution: lazy instantiation for specified polytypes This rea¬ 
soning, inspired by thinking about how to extend the declarative 
specification of the HM type system, has lead us to develop a novel 
algorithm for type inference. This algorithm, which we call Algo¬ 
rithm V, is based on the following design principle: 

Delay instantiation of “specified” type parameters until 
absolutely necessary. 

Although Algorithm W instantiates all polytypes immediately, 
it need not do so. In fact, it is possible to develop a sound and 
complete alternative implementation of the HM type system that 
does not do this immediate instantiation. Instead, instantiation is 
done only on demand, such as when a polymorphic function is 
applied to arguments. 

In the next section, we give this algorithm a simple specifica¬ 
tion, presented as a small extension of HM’s existing declarative 
specification. We then make the details of our algorithm precise by 
giving a syntax-directed account of the type system, characterizing 
where lazy instantiations actually must occur during type checking. 

4. HM with visible type application 

To make our ideas precise, we next review the declarative specifi¬ 
cation of the HM type system 0[l7) (which we call System HM), 
and then show how to extend this specification with visible type 
arguments. 

4.1 System HM 

The grammar of System HM is shown in Figure [2] The expression 
language comprises the Curry-style typed A-calculus with the ad- 

7 In fact, the Haskell 2010 Report (T4) defines type annotations by expand¬ 
ing to a let-declaration with a signature. 
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type schemes 
typing contexts 
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HM_VAR 
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r Ihm Xx. 6 : Tl —¥ T 2 


HM_ABS 


Figure 2. Grammar for System HM 


HM_APP 


dition of numeric literals (of type Int ) and let-expressions. Mono¬ 
types are standard, but we quantify over a possibly-empty set of 
type variables in type schemes. Here, we diverge from standard no¬ 
tation and write these type variables in braces to emphasize that 
they should be considered order-independent. We sometimes write 
r for the type scheme V{ }. r with an empty set of quantified vari¬ 
ables, and write V{a}.V{6}.r to mean V{o, 6}.r. Here - and 
throughout this paper - we liberally use the Barendregt convention 
that bound variables are always distinct from free variables. 

The declarative typing rules for System HM appear in Figure[3] 
(This figure also includes rules for our extended system, called 
System HMV, described in Section |4~2| ) System HM is not syntax- 
directed - rules HM_Gen and HM_Sub can apply anywhere. 

So that we can better compare this system with others in the 
paper, we make two small changes to the standard HM rules. 
Neither of these changes are substantial; our version types the same 
programs as the original. First, we allow the type of a let expression 
to be a polytype a, instead of restricting it to be a monotype t. (We 
discuss this change further in Section |5^2| ) Second, we replace the 
usual instantiation rule with HM_SUB. This rule allows the type of 
any expression to be to converted to any less general type in one 
step (as determined by the subsumption relation ay <(, m cr 2 ). Note 
that in rule HM_InstG the lists of variables ai and 0,2 need not be 
the same length. 


rLn: Int 

r him ei : 0-1 r, x:cr\ t^m e 2 : ay 
T let x = e\\n 62 '■ 02 

Tk m e:a a <£ ftv(T) TT , 

-™ 

rLe:<n (71 <hm CT 2 


a 1 <hm 0-2 


n[r/ai] - T 2 a 2 g /tu(V{ai}. n) 

V{ai}. Tl < hm V{a 2 }. t 2 

| r fc mv e : a | Extra typing rules for System HMV 
r closed T lfimv e : Va. 


T l* mv e @t : v[r/a] 


HMV_TAPP 


4.2 System HMV: HM with visible types 

System HMV is an extension of System HM, adding visible type 
application. A key detail in its design is its separation of specified 
type variables from thos e arising from generalization, as initially 
explored in Section |3. 1 1 Types may be generalized at any time in 
HMV, quantifying over a variable free in a type but not free in 
the typing context. The type variable generalized in this manner is 
not specified, as the generalization takes place absent any direction 
from the programmer. By contrast, a type variable mentioned in a 
type annotation is specified, precisely because it is written in the 
program text. 

4.2.1 Grammar 

The grammar of System HMV appears in Figure [4] The type lan¬ 
guage is enhanced with a new intermediate form v that quantifies 
over an ordered list of type variables. This form sits between type 
schemes and monotypes; as contain vs, which then contain rsQ 
Thus the full form of a type scheme a is V{a}, b. t, including both 
a set of generalized variables {a} and a list of specified variables 
6. Note that order never matters for generalized variables (they are 
in a set) while order does certainly matter for specified variables 


8 The grammar for System HMV redefines several metavariables. These 
metavariables then have (slightly) different meanings in different sections 
of this paper, but disambiguation should be clear from context. In analysis 
relating systems with different grammars (for example, in Lemma[TJ, the 
more restrictive grammar takes precedence. 


I 0-1 <hmv <7 


r bimv (e : v) : 


Tl[r /b\ = T2 


HMV_Annot 


Va, b. Ti <hmv Va. T2 

[t/oi] < hmv V 2 0,2 g ftv (V{til}. Uj) 
V{ai}. v 1 <hmv V{a 2 }. v 2 


Figure 3. Typing rules for Systems HM and HMV 


The grammar for HMV extends that for System FIM (Figure|2]l: 


... | e @r | (e : v) expressions 
monotypes 

Va. r specified polytypes 

V{a}.w type schemes 

• | T,x:o contexts 


Figure 4. Grammar for System HMV 
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V{a, b}. a —t b 

< hm „ V{a}. a -a a 

Va, b. a -¥ b 

<hmv Int — »• Int 

Va, b. a —¥ b 

<hmv Va. a -A Int 

Va, b. a -a b 

< hmi V{a,(i}.aTi 

Va, b. a -a b 

<hmv V{ b}. Int -A b 

Va, b. a -a b 

£hmv V&. Int -A b 

V{a}. a —¥ a 

£ hmu Va. a -A a 


Works the same as <hm for type schemes 
Can instantiate specified variables 
Can instantiate only a tail of the specified variables 
Variables can be regeneralized 

Because of the right-to-left nature of HMV_InstS, must regeneralize 
Known variables are instantiated from the right, never the left 
Specified quantification is more general than generalized quantification 


Figure 5. Examples of HMV subsumption relation 


(the list specifies their order). We say that v is the metavariable for 
specified polytypes, distinct from type schemes a. 

Expressions in HMV include two new forms: e @r instantiates 
a specified type variable with a monotype t, while (e : v) allows us 
to put a type annotation on an expression. These type annotations 
are specified polytypes v and must not contain any free type vari¬ 
ables. (We lift this restriction in Section [6~j~[ ) We do not allow an¬ 
notation by type schemes a, with quantified generalized variables: 
if the user writes the type, all quantified variables are considered 
specified. 

4.2.2 Typing rules 

The type system of HMV includes all of the rules of HM plus 
the new rules and relation shown at the bottom of Figure [3] The 
HMV rules inherited from System HM are modified to recur back 
to System HMV relations: in effect, replace all hm subscripts 
with hmv subscripts. Note, in particular, rule HM_Sub; in System 
HMV, this rule refers to the cri <hmv cr 2 relation, described below. 

The most important addition to this type system is 
HM V_TApp, which enables visible type application when the type 
of the expression is quantified over a specified type variable. 

Type annotations, typed with HMV_Annot, allow expressions 
to be assigned a specified polytype v = Va. r. The rule checks 
to make sure v is closed and then types the expression e at type 
t. Of course, in the T e : r premise, the variables a still 
(perhaps) appear in r, but they are no longer quantified. We call 
such variables skolems and say that skolemizing v yields r. In 
effect, these variables form new type constants when type-checking 
e. When the expression e has type r, we know that e cannot make 
any assumptions about the skolems a and that we can assign e the 
type Va. r. This is, in effect, specified generalization. 

The relation cri <hmv crz (Figure [3j implements subsumption 
for System HMV. The intuition is that, if cri <hmv 02, then an 
expression of type cri can be used wherever one of type a 2 is 
expected. For type schemes, the standard notion of cri being a more 
general type than a 2 is sufficient. However for specified polytypes, 
we must be more cautious. 

Suppose an expression x @ti @t 2 type checks, where x has 
type Va, b.v i. The subsumption rule means that we can arbitrarily 
change the type of x to some v, as long as v <hmv Va, b.v i. 
Therefore, v must be of the form Va, b.v 2 so that x @ti @t 2 will 
continue to instantiate a with n and b with t 2 . Accordingly, we 
cannot, say, allow subsumption to reorder the specified variables. 

However, it is safe to allow some instantiation of specified 
variables as part of subsumption, as in ruleHMV_lNSTS. Examine 
this rule closely: it instantiates variables from the right. This odd¬ 
looking design choice is critical. Continuing the example above, v 
could also be of the form Va, 6, C.V 3 . In this case, the additional 
specified variable c causes no trouble - it need not be instantiated 
by a visible application. But we cannot allow instantiation left- 
to-right as that would allow the visible type arguments to skip 
instantiating a or b. 

Further examples illustrating <(, mv appear in Figure[5] 


4.3 Properties of System HMV 

We wish System HMV to be a conservative extension of System 
HM. That is, any expression that is well-typed in HM should 
remain well-typed in HMV, and any expression not well-typed in 
HM (but written in the HM subset of HMV) should also not be 
well-typed in HMV. 

Lemma 1 (Conservative Extension for HMV). Suppose T and e 
are both expressible in HM; that is, they do not include any type 
instantiations, type annotations, scoped type variables, or specified 
poly types. Then, T b; m e : a if and only ifT b; mv e : a. 

This property follows directly from the definition of HMV as 
an extension of HM. Note, in particular, that no HM typing rule 
is changed in HMV and that the <hmv relation contains <hm ; 
furthermore, the new rules all require constructs not found in HM. 

We also wish to know that making generalized variables into 
specified variables does not disrupt types: 

Lemma 2 (Extra knowledge is harmless). IfT, x:V{a}. r ^ mw e : 
o, then T, x:Va. r e : cr. 

This property follows directly from a context generalization 
lemma, stated and proven in Appendix |B| which states that we can 
generalize types in the context without affecting typability. Note 
that Va. r <h mv V{a}. r. 

In practical terms. Lemma [2] means that if an expression con¬ 
tains lets = ei in e 2 , and the programmer figures out the type 
assigned to x (say, V{a}.T) and then includes that type in an an¬ 
notation (as let x = (ei : Va. r) in e 2 ), that the expression’s type 
does not change. 

However, note that, by design, context generalization is not as 
flexible for specified polytypes as it is for type schemes. In other 
words, suppose the following expression type-checks. 

let x = ((Ax -A x) :: V a b. (a, b) -A (a, b)) in ... 

The programmer cannot then replace the type annotation with the 
type V a. a —t a, because x may be used with visible type applica¬ 
tions. This behavior may be surprising, but it follows directly from 
the fact that V a. a —¥ a ^hmv Vafe. (a, b) -A (a, b). 

Finally, we would also like to show that a system with visible 
types retains the principal types property, defined with respect to 
the enhanced subsumption relation o\ <hmv cr 2 . 

Theorem 3 (Principal types for HMV). For all terms e well-typed 
in a context T, there exists a type scheme a p such that T e : cr p 
and, for all a such that T e : cr, cr p <hmv cr. 

Before we can prove this, we first must show how to extend 
HM’s type inference algorithm (Algorithm W QD) to include vis¬ 
ible type application. Once we do so, we can prove that this new 
algorithm always computes principal types. 

5. Syntax-directed versions of HM and HMV 

The type systems in the previous section declare when programs 
are well-formed, but they are fairly far removed from an algorithm. 
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r, xvn k e : T2 
r Xx. e : Ti —>• t 2 


Typing rules for System C 


i:V{s}.rer 

Tkx:r[r/a] 


C_Var 


V_Abs 


P% ei : n —> t 2 I’ •„ p -2 : n 
r 61 e 2 : T2 


V_App 


r c - 


: n —> T2 T l c e 2 ■ Ti 
r t ei e 2 : T2 


C_App 


r ^ n : Int 


V_Int 


r t n : Int 


C_Int 


r tf n e : a r, x:<j k e 2 : r 2 
r t let X = ei in e 2 : r 2 


C_Let 


r £ e : Vo. t 
no other rule matches 


Five: r[r/a] 


V_InstS 


l F e«H 


| T l| en e : a | Generalization for System C 

a = ftv(r)\Mr) T^eir 

r e : V{o}. r 


C_Gen 


We use ftv{d) to mean the free type variables of a type scheme cr. 
We lift this to work on contexts: ftv(xur) = U ftv(ai). 


Figure 6. Syntax-directed version of the HM type system 


**{*}.« er 
r %x:v[T/a] 


V_Var 


r \f n ei : (j i r, X'.cn lv e 2 : u 2 

r let x = ei in e 2 : u 2 


V_Let 


r closed I 1 1* r : Va. v 
r ^ e @r : v[r/a] 


V_TApp 


v closed v = Va. r T ^ e : r 

In particular, the rules HM_Gen and HM_SUB can appear at any - p p ( e ■ v ) ■ v - V_ANNOT 

point in a typing derivation. v ' > ' 


5.1 System C 

We can explain the HM type system in a more algorithmic manner 
by using a syntax-directed specification, called System C, in Fig¬ 
ure [6] This version of the type system, derived from Clement et al. 
0, clarifies exactly where generalization and instantiation occur 
during type checking. Notably, instantiation occurs only at the us¬ 
age of a variable, and generalization occurs only at a let-binding. 
These rules are syntax-directed because the conclusion of each rule 
in the main judgment T t e : r is syntactically distinct. Thus, from 
the shape of an expression, we can determine the shape of its typing 
derivation. 

However, the judgment T ^ e : t is still not quite an algo¬ 
rithm: it makes non-deterministic guesses. For example, in the rule 
C_Abs, the type n is guessed; there is no indication in the expres¬ 
sion what the choice for n should be. The advantage of studying 
a syntax-directed system such as System C is that doing so sepa¬ 
rates concerns: System C fixes the structure of the typing derivation 
(and of any implementation) while leaving monotype-guessing as 
a separate problem. Algorithm W guesses the monotypes via uni¬ 
fication, but a constraint-based approach (25] (27) would also work. 

5.2 System V: Syntax-directed visible types 

Just as System C is a syntax-directed version of HM, we can also 
define System V, a syntax-directed version of HMV (Figure |7}. 
However, although we could define HMV by a small addition to 
HM (two new rules, plus subsumption), the difference between 
System C and System V is more significant. 

Like System C, System V uses multiple judgments to restrict 
where generalization and instantiation can occur. In particular, the 
system allows an expression to have a type scheme only as a result 
of generalization (using the judgment T \^ en e : a). Generalization 
is, once again, available only in let-expressions. 


io other rule matches 


\r\* m e 


= ftv(v)\ftv(T) 

: V{a}. i 


Figure 7. Typing rules for System V 


However, the main difference that enables visible type anno¬ 
tation is the separation of the main typing judgment into two: 
r t e : r and T ^ e : v. The key idea is that, sometimes, we 
need to be lazy about instantiating specified type variables so that 
the programmer has a chance to add a visible instantiation. There¬ 
fore, the system splits the rules into a judgment k} that requires e to 
have a monotype, and those in hj that can retain quantification in a 
specified polytype. 

The first set of rules in Figure [7] as before, infers a monotype 
for the expression. The premises of the rule V_Abs uses this 
judgment, for example, to require that the body of an abstraction 
have a monotype. All expressions can be assigned a monotype; if 
the first three rules do not apply, the last rule V_InstS infers a 
polytype instead, then instantiates it to yield a monotype. Because 
implicit instantiation happens all at once in this rule, we do not need 
to worry about instantiating specified variables out of order, as we 
did in System HMV. 
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The second set of rules (the hj judgment) allow e to be assigned 
a specified polytype. Note that the premise of rule V_TApp uses 
this judgment. 

System V’s VJVar rule is like System C’s C_Var rule: both 
look up a variable in the environment and instantiate its generalized 
quantified variables. The difference is that C_Var’s types can 
contain only generalized variables; System V’s types can have 
specified variables after the generalized ones. Yet we instantiate 
only the generalized ones in the V_Var rule, lazily preserving the 
specified ones. 

Rule V_Let is similar to C_Let. The only difference is that the 
result type is not restricted to be a monotype. By putting V_Let in 
the Ij judgment and returning a specified polytype, we allow the 
following judgment to hold: 

• lv (leta; = (At/, y : Vo. a —»• a) ins) @lnt : Int -A Int 
The expression above would be ill-typed in a system that restricted 
the result of a let-expression to be a monotype. It is for this reason 
that we altered System HM to include a polytype in its HM_Let 
rule, for consistency with HMV. 

Rule V_Annot is identical to rule HMV_Annot. It uses the 
^ judgment in its premise to force instantiation of all quantified 
type variables before regeneralizing to the specified poly type v. In 
this way, the V_Annot rule is effectively able to reorder specified 
variables. Here, reordering is acceptable, precisely because it is 
user-directed. 

Finally, if an expression form cannot yield a specified polytype, 
rule V_Mono delegates to (7 to find a monotype for the expression. 

5.3 Relating System V to System HMV 

Systems HMV and V are equivalent; they type check the same 
expression. We prove this correspondence using the following two 
theorems. 


The grammar for B extends that for System HMV (Figure[4]l: 


p 

::= T | Wi —>• 

p2 rho-types 

0 

:: = T j Vi —>• 

V2 phi-types 

V 

::= Vo. <j> 

specified polytypes 

0 

::= V{a}. v 

type schemes 

r 

::= • | r, x:o 

| T, a contexts 


T F v | Type well-formedness 

ftv(v) c r 


Synthesis rules for System B 


T ^ As. e =F 
T ^ ei =► vi -A v 2 


> o 1 r, a::cri Ig & 


Theorem 4 (Soundness of V against HMV). 

1. IfTke- t, then V ^ e : r. 

2. IfT £ e : v, then r ln mv e : v. 

3. IfT If" e : 0, then T e : a. 

Theorem 5 (Completeness of V against HMV). If T j; mv e : a, 
then there exists o' such that T f n e : a' where o' <hm» o. 

The proofs of these theorems appear in Appendix |C| 

Having established the equivalence of System V with System 
HMV, we can note that Lemma|2] (“Extra knowledge is harmless”) 
carries over from HMV to V. This property is quite interesting in 
the context of System V. It says that a typing context where all 
type variables are specified admits all the same expressions as one 
where some type variables are generalized. In System V, however, 
specified and generalized variables are instantiated via different 
mechanisms, so this is a powerful theorem indeed. 

It is mechanical to go from the statement of System V in Fig- 
ure[7]to an algorithm. In Appendix|D| we define Algorithm V which 
implements System V, analogous to Algorithm W which imple¬ 
ments System C. We then prove that Algorithm V is sound and 
complete with respect to System V and that Algorithm V finds prin¬ 
cipal types. Linking the pieces together gives us the proof of the 
principal types property for System HMV (Theorem [3j. Further¬ 
more, Algorithm V is guaranteed to terminate, yielding this theo- 


r^e=^V{a}.cr 

r ^ e =4- ei 01 <b 02 
T ^ e => 02 

r h r rte^Va.-t; 

T ^ e @r =$■ v[r/ a] B - 

v — Vo. (f) r ,a^e<=(j) 

r^( e :t>)^« 

| Checking rules for System B 
T, x:vi ^ e v 2 „ 


r^\x.e<=V!^-V2 

r lb ei =S> CTi r, x:oi I5 e 
T ^ let x = ei in e 2 1 


r t e ^ v at nars(r) 
ri^ e^Va.u 


Theorem 6. Type-checking System V is decidable. 

6. Higher-rank type systems 

We now extend the design of System HMV to include two ex¬ 
tensions of the Flindley-Milner type system: higher-rank polymor- 


r lb e =£- 01 01 <dsk V2 

r ^ e V2 


B_Infer 


Figure 8. Grammar and typing rules for System B 


2015/7/10 























| Oi <fa <72~| Higher-rank instantiation 

—— B_Refl 


V3 <b Vl 
VI —t V2 <b 


fa[r/b\ < b fa 
Va, b. fa <b Va. fa 


B_InstS 


vi [r/a] <b v 2 b 0 ftv(V{a}. vi) 
V{a}. vi < b V{b}.V2 


B_InstG 


fa <j sk p2 Subsumption, after deep skolemization 


DSK_Refl 


«3 <dsk Vl V2 <dsk p4 
Vl —>• V2 <j sk V3 -t pA 


DSK_FUN 


Visible type application means that higher-rank arguments can 
also be explicitly instantiated. For example, we can instantiate 
lambda-bound identifiers 

let foo :: (V a. a — > a) —>■ ( Int — » Int, Bool) 
foo = Xf -¥ (f @lnt, f True) 
in foo id 

Higher-rank types also mean that visible instantiations can oc¬ 
cur after other arguments are passed to a function. For example, 
consider this alternative type for the pair function 
pair :: V a. a —>■ V b. b —k (a, b) 
pair = Xx y -¥ (x, y) 

If pair has this type, we can instantiate b after providing the first 
component for the pair, thus 
bar = pair 2 @ Bool 

— bar inferred to have type Bool —> (Int, Bool) 

In the rest of this section, we provide the technical details of 
these language features and discuss their interactions. As above, we 
start with a declarative specification of the type system, and then 
discuss its implementation through an equivalent syntax-directed 
variant. The syntax-directed system studied here is the basis of our 
implementation in GHC. 


| Pi <dsk r^T| Subsumption, with deep skolemization 


prenex(v 2) = Vc. p2 
fa[r/g][r/b\ <d 5k p2 
V{o},b.fa <dsk v 2 


DSK_INST 


Define prenex(v) = V a. p as follows: 

prenex (Va. r) = Vo. r 

prenex(Va. vi -»• vf) = Vo, 6. vi -y p 2 
where V6.P2 = prenex (v 2) 


Figure 9. Subsumption relations for System B 


phism and scoped type variables. The former allows function pa¬ 
rameters to be used at multiple types, whereas the latter brings type 
variables into scope to be used in type annotations. Incorporating 
these extensions shows the generality of our work. Although these 
extensions come with their own complexities, there are no unpleas¬ 
ant interactions in the introduction of visible type application. 

In fact, there is synergy between higher-rank polymorphism 
and visible type application. GHC supports higher-rank polymor¬ 
phism (T6) (23) through the use of programmer annotations. As in 
visible type application, this type system feature is enabled only for 
polytypes that have been specified through some type annotation. 

For example, the following function does not type check in 
the vanilla Hindley-Milner type system, assuming id has type 


let foo = Xf -¥ (f 3, f True) in foo id 

Yet, with the RankNTypes language extension and the following 
type annotation, GHC is happy to accept this code 

let foo :: (V a. a —t a) —t (Int, Bool) 
foo = Xf —t(f3,f True) 


6.1 System B: Declarative specification 

Figures [8] and [9] show the syntax and typing rules of System 
B, a declarative bidirectional type system, supporting predicative 
higher-rank polymorphism, visible type application, and scoped 
type variables. This declarative type system itself is a novel contri¬ 
bution of this work. Although it is based on the type system studied 
by Peyton Jones et al. (23], that work uses only a syntax-directed 
system to describe bidirectional propagation of higher-rank types. 

System B is defined by two mutually recursive judgments, T (5 
e => o and r ^ e <= v, specifying when types are synthesized 
and checked, respectively. In the first judgment, the type o is an 
output of the system, whereas in the second, the type v must be 
provided along with F and e. This system propagates specified type 
information through the abstract syntax tree via its T ^ e <= v 
judgment. 

Although this system is bidirectional, we also claim that it is 
declarative. In particular, the use of generalization (B_Gen), sub¬ 
sumption (B_Sub), skolemization (B_Skol), and mode switching 
(B_lNFER), can happen arbitrarily in a typing derivation. Under¬ 
standing what expressions are well-typed does not require knowing 
precisely when these operations take place. 

Basic features of System B System B shares the same expression 
language of Systems HMV and V, retaining visible type application 
and type annotations. However, types in System B may have non- 
prenex quantification. The body of a specified polytype v is now a 
phi-type <j>: a type that has no top-level quantification but may have 
quantification to the left or to the right of arrows. Note also that 
these inner quantified types are vs, not os. In other words, non- 
prenex quantification is only over specified variables, never gener¬ 
alized ones. As we will see, inner quantified types are introduced 
only by user annotation, and thus there is no way the system could 
produce an inner type scheme, even if the syntactic restriction were 
not in place. Typing contexts V may now contain type variables; 
this change is used to implement scoped type variables. The func¬ 
tion vars( r) calculates all type variables that occur in T, including 
both the declared scoped type variables and the free type variables 
in typing assumptions. 

Type synthesis The synthesis judgment is identical to the typing 
judgment for F1MV if we ignore direction arrows. This is unsurpris- 
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Va. a -4 V6. 6 -4 6 
Va. a -4 V6. 6 -4 b 
Va. a -4 V6. b -4 b 
(Int —t /nt) -4 Bool 


Int -4 Bool —> Bool 
Int -4 V6. 6—^6 
Va. a -4 Bool -4 Bool 
(Va. a -4 a) -4 Bool 


Int -4 Va, b. a b 
Int -4 Va. a —>• a 


Int -4 V6. Bool -4 
Va. Int -t a-t a 


Can instantiate non-top-level variables 

The levels are independent; not all variables must be instantiated 
The levels are independent; we can skip a top-level quantifier 
<b supports contravariant instantiation through higher-rank types 
Specified variables are instantiated from the right 
Cannot move quantifiers for specified variables 


Int -4 Va, b.a -t b <dsk Int -4 V6. Bool -4 6 
Int -4 Va. a -4 a <d s k Va. Int —> a —> a 
(Int -4 V6. &—>■&)—>■ Int < dsk (Va, 6. a -4 6 -4 6 ) -4 Int 
V{a}. a -4 a < dsk Va. a -4 a 


<dsk can instantiate specified variables in any order 

Specified quantification can move with < dsk 

Out-of-order instantiation works contravariantly through arrows 

< dsk ignores the distinction between specified and generalized variables 


Figure 10. Examples of B subsumption, with both relations 


ing, as the previous systems essentially all work only in synthesis 
mode; they derive a type given an expression. The novelty of a bidi¬ 
rectional system is its ability to propagate type information toward 
the leaves of an expression. 

The subsumption rule (B_Sub) in the synthesis judgment cor¬ 
responds to HMV_SUB from HMV. However, the novel subsump¬ 
tion relation <b used by this rule, shown at the top of Figure [9] is 
one of two subsumption relations that appear in the type system. 
This oi <b <T2 judgment extends the action of <hmv to higher- 
rank types: in particular, it allows subsumption for generalized type 
variables (which can be quantified only at the top level) and in¬ 
stantiation for specified type variables. We sometimes say that this 
judgment enables inner instantiation because instantiations are not 
restricted to top level. Figure[l0|provides examples of this relation. 

Type checking The checking rules allow the higher-rank type 
system to take advantage of specified polytypes. This happens in 
two different ways. 

Rule B_DAbs is the key rule of the checking judgment. When 
we have propagated a type ui -4 vi for an expression \x. e, 
B_DAbs uses the type vi as x’s type when checking e. This is 
the only place where we can type a function with a higher-rank 
type. Note that the synthesis rule B_Abs uses a monotype for the 
type of xQ 

Rule B_Infer uses the stronger of the two subsumption rela¬ 
tions <dsk, shown at the bottom of Figure [9] and with examples in 
Figure [To| This rule appears at precisely the spot in the derivation 
where a specified type from synthesis mode meets the specified 
type from checking mode. This relation, called deep skolemization, 
we take directly from prior work 1231 . It subsumes <b (that is, 
<7i <b V2 implies <7i < dsk V2) and provides a full subsumption 
relationship for higher-rank types. 

For brevity, we don’t explain the details of this relation here, in¬ 
stead referring readers to Peyton Jones et al. (Section 4.6) HD for 
much deeper discussion. However, we note that there is a design 
choice to be made here; we could have also used Odersky-Laufer’s 
slightly less expressive higher-rank subsumption relation (20l in¬ 
stead. We present the system with deep skolemization for back¬ 
wards compatibility with GHC. See Appendix [G| for a discussion 
of this alternative. 

Rule B_Skol skolemizes one variable - that is, if we are 
propagating a type quantified over a (specified) variable a, we 
continue propagating without the quantification. Like other steps 


9 Higher-rank systems can also include an “annotated abstraction” form, 
\x:v. e. This form allows higher-rank types to be synthesized for lambda 
expressions as well as checked. However, this form is straightforward to 
add but is not part of GHC, which uses patterns (beyond the scope of this 
paper) to bind variables in abstractions. Therefore we omit the annotated 
abstraction form from our formalism. 


that skolemize, this turns the quantified variable effectively into 
a type constant. This rule is necessary in order to remove any 
outer quantification before rule B_DAbs can apply. Note that when 
we talk about skolemization, we are considering reading the rule 
“bottom-to-top” - the order of the checking propagation. If we read 
the rule “top-to-bottom”, then this is a simple V-introduction, or 
generalization, rule. 

The remaining checking rule, B_DLet, simply propagates type 
information into the body of a let-expression. 

Scoped type variables Scoped type variables increase the expres¬ 
siveness of our system; they were necessary for both examples in 
Section [2] Therefore, System B relaxes the HMV restriction that 
type annotations and instantiations must be closed. Instead, type 
annotations are allowed to introduce type variables, which are then 
in scope inside the annotation. 

This behavior matches that of GHC (2T}. For example, the type 
annotation on const below introduces the type variables a and b 
that can then be used in the definition of const. 

const = (Ax y -4 (x :: a) :: V a b. a -4 b -4 a) 

System B only introduces type variables in B_Annot, and there 
only variables quantified at the top level. 

An alternative design would be to introduce scoped type vari¬ 
ables in B_Skol instead of B_Annot. (Note that the skolemized 
variables are not brought into scope in that rule). However, we de¬ 
liberately avoided this design because it leads to strange scoping 
behavior, as we describe in Appendix |G| 

6.2 System SB: Syntax-directed Bidirectional type checking 

System B is a declarative type system and not an algorithm. Fig- 
ure[TT]shows the higher rank analogue of System V, called System 
SB. As with other syntax-directed systems, the form of the rule 
conclusions resolve the order in which the rules must be applied. 
System C shows how to restrict generalization to happen only in 
let-bindings; this treatment is retained through all of the systems in 
this paper. System V shows how to restrict instantiation: instantiate 
generalized variables eagerly at variable usage sites, and instanti¬ 
ate specified variables lazily, on demand. System SB must now fix 
the new declarative rule that can apply anywhere: skolemization. 
System SB requires all skolemization to occur first when check¬ 
ing: SB_DeepSkol is the only rule in the T lf b e <= v judgment, 
and is also the entry point for the non-skolemizing T Ig, e <= p 
judgment^ 

The interaction between rule SB_DeepSkol and SB_lNFER 
is subtle, due to the use of deep skolemization as our higher- 


10 Our choice to skolemize before SB_DLet is arbitrary, as SB_DLet 
does not interact with the propagated type. 
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| r tjb e =>■ 0 | Synthesis for 0-types 


r, x:r i| b ( 
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SB_Int 
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r 4 e ^ Vo. 0 
no other rule matches 

r Isi, e =?• 0[r'/'ii] " 

| Synthesis for u-types 
a::V{o}. w£f 


r ■ h . 


[r/o] 


r if b < 


r lf b let x = ei in ei =>• u; 

r i- r rif b e => Vo. w 
r f b e @T ^ v[r/a] 

u = Va.0 T,a i| b . 


r ^ (e : v) = 


I r Iff" e 


Synthesis and generalization 


rank subsumption relation. Note that SB_DeepSkol does not 
directly match up with B_Skol. It doesn’t just skolemize the top- 
level quantified variables; it skolemizes all positively quantified 
variables. For example, if the algorithm is checking against type 
Vo. a —>■ V6. b —>■ a, it will skolemize both a and b, pushing in 
the type a —> b —> a. In fact, the post-skolemization checking 
judgment r Ig, e <*= p, requires that the provided type be a p- type 
- one with no quantifiers to the right of arrows. 

Deep skolemization is necessary in SB_DeepSkol because 
SB_Infer uses the r [j b e => v synthesis judgment in its premise, 
instead of the T lf b n e => a judgment. This decision to avoid 
generalization was forced by GHC, where generalization is intri¬ 
cately tied into its treatment of let-bindings and not supported for 
arbitrary expressions. Compare SB_Infer with B_Infer, whose 
premise synthesizes a cr-type. This difference means that, in the 
syntax-directed system, we require more instantiations in the typ¬ 
ing derivation above the SB_Infer rule. If the checked type were 
not deeply skolemized, certain inner-quantified variables would be 
unavailable for instantiation. For an illuminating example, see Fig¬ 
ure^ 

Properties of System B and SB System SB faithfully implements 
System B. 

Lemma 7 (Soundness of System SB). 

1. IfT ^ e =► 0 then T ^ e => 0. 

2. IfT lf b e=»• v then T e =* v. 

3. IfT If" e => a then T ^ e => o. 

4. IfT ^ e <= v thenT k e <^= v. 

5. IfT lib e p then T e <= p. 

Lemma 8 (Completeness of System SB). 

1. IfT fh e => a then T if™ e => a' where a' < b o. 

2. IfT ^e<=v then T & e <= v. 

Furthermore, we also show that System B is flexible with re¬ 
spect to the instantiation relation < b . As in System HMV, this re¬ 
sult implies that making generalized variables into specified vari¬ 
ables does not disrupt types. 


r 4 e =F « d = ftv(v) \ vars(T) 
rf™ e^X/{a}.v 


SB_Gen 


| F Ijh e <= p | Checking a p-type 


Lemma 9 (Context Generalization). Suppose T' < b T. 

1. IfT Ig e =>• <7 then there exists o' < b a such that T' ^ e =>• o'. 

2. IfT^e<=v andv < b v' then T' k e <= v'. 

Proofs of these properties appear in Appendix[F| 


T, x-.vx 4 e p 2 
r Ijh Xx. e <= vi —>■ p2 


SB_DAbs 


r If™ ei =t- tn T, asicri kb e 2 <= P 2 
T la, let x = ei in e 2 <= p2 


SB_DLet 


7. Integrating visible type application with GHC 

System SB is the direct inspiration for the type-checking algorithm 
used in our version of GHC enhanced with visible type applica¬ 
tion. Below, we describe describe interactions between visible type 
application and other features of GHC. 


r 4 e Ui Vi <dsk P2 
no other rule matches 

-—- SB Infer 

F la, e <= P 2 

| T lf b e <= u | Checking a i;-type 


7.1 Case expressions 

Typing rules for case analysis and if-expressions require that all 
branches have the same type. But what sort of type should that be? 
For example, consider the following expression 
if condition then id else (Ax —t x) 


prene x(v) = Va.p 
a £ mr-s(r) T U 
r lf b e 4= V 




SB_DeepSkol 


Figure 11. Syntax-directed bidirectional type system 


Here, id has a specified polytype of V a. a —t a, but the expression 
Ax —t x does not. To make this code type check, GHC must find a 
common type for both branches. 

One option would be to generalize the type of Ax -> x and 
then choose V a. a —>• a as the common supertype of itself and 
V{a}. a —t a. However, that may not be possible in general, as 
there may not always be a common instance of both types. 
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t. We wish to type-check the expression ( x.lnt —> Va. 


Assume T = a;:V{a}. Int a a 


a —¥ a). Here is a valid derivation in System B: 


r ^ x => V{a}. Int - 


Here is a valid derivation in System SB: 


B_InstG 

B_Infer 


z:V{a}. Int^-a^-aeT 
T \l b x ^ Int ^ a ^ a 


SB_Var 


Int —> 
Int —> 


T kbx^lnt^a^ a 
r | b x Int Va. a —> 
r lf b (x : Int —> Va. a —t a) =4- Int - 
T & en (x : Int -+Va.04a)=i- Int 


-A a <3 sk Int —> a —>• a 
-»• a <dsk Int —> a —>• a 


DSK_Refl 

DSK_Inst 

SB_Infer 


- SB_DeepSkol 

-SB_Annot 

Va. a -4 a 

-SB_Gen 


Note the deep skolemization in this derivation. If we did only a shallow skolemization at the point we use SB_DeepSkol, then a would not 
be skolemized. Accordingly, it would be impossible to instantiate the type of x with a in the use of the SB_Var rule. 


Figure 12. An example of why deep skolemization in SB_DeepSkol is necessary 


Instead, following prior work (23], we require that if and case 
expressions synthesize monotypes. Accordingly, the type checker 
instantiates the type id above before unification. 

Note that specified poly types are still available for type check¬ 
ing because we know the type that each branch should have. For 
example, the following declaration is accepted 
checklf :: Bool — > (V a. a — > a) —>■ (Bool, Int ) 
checklf b = if True 
thenA/" — > (f True, f 5) 
else A f —t (f False, f 3) 

7.2 Imported functions 

The key requirement of specified polytypes is that type variables 
are fixed and known to programmers. But, when is this the case? 

In the design of our implementation, we considered the pos¬ 
sibility that all imported functions could meet this requirement. 
This would allow visible type application for any imported func¬ 
tion, whether or not it was originally supplied with a type annota¬ 
tion. This decision is justified: programmers can use tools (such 
as ghci’s :browse command) to discover the types. This deci¬ 
sion also places the least burden on programmers, as library au¬ 
thors need not think about visible type application when deciding 
whether to specify the types of their functions. 

However, this design is also fragile. By allowing all imported 
functions to be visibly instantiated, the ordering of type variable 
quantification is now part of the specification of the function. Per¬ 
haps worse, there is no guarantee that this ordering will stay the 
same from one version of the compiler to the next. 

Furthermore, it is also unnecessary. Haskell library authors al¬ 
ready do put type signatures on many of their exported functions. 
For functions exported without a type signature, clients may easily 
add their own type specifications by rebinding imported functions. 

We thus chose the conservative design. Only imported functions 
with type signatures are considered to have specified types P] 

7.3 Partial type signatures 

Partial type signatures 129) are a recent addition to GHC, allowing 
users to leave wildcards in types, allowing GHC to infer those parts 


11 If the type signature does not include an explicit V listing the type vari¬ 
ables, we use the order as they appear in the user-supplied type signature. 


of a type. Wildcards can appear in visible type arguments, allowing 
users to skip types GHC can infer. For example, if f has type 
V a b. a — > b —>■ (a, b ), then we can write f @[lnt} True [] 
to let GHC infer that a should be Bool but to visibly instantiate b to 
be [Int], The existing partial type signatures machinery simply fills 
in the wildcard by unification, as it does when wildcards appear in 
type signatures. 

7.4 Futher extensions to visible type application 

Our implementation also gives us the chance to explore two related 
extensions in future work. 

Visible type binding in patterns Consider the following GADT 
data G a where 

MkG :: V b. G (Maybe b) 

When pattern-matching on a value of type G a to get the construc¬ 
tor MkG, we would want a mechanism to bind a type variable to b, 
the argument to Maybe. A visible type pattern makes this easy 
case g of 

MkG @b-> ... 

The type variable b may now be used as a scoped type variable in 
the body of the match. 

Visible kind application The following function is kind- 
polymorphic l30l 

pr :: V (a :: k\ —>• k 2 ) (b :: k\). Proxy (a b) —► Proxy a 
pr _ = Proxy 

Yet, even with our extension, we cannot instantiate the kind param¬ 
eters k\ and k 2 visibly; all kind variables are treated as generalized 
variables. We expect to address this deficiency in future work. 

8. Related work and Conclusions 

Implicit arguments in dependently-typed languages Languages 
such as Coq |6|, Agda (T5), Idris Q] and Twelf (ft) are not based 
on the HM type system, so their designs differ from Systems HMV 
and B. However, they do support invisible arguments. In these 
languages, an invisible argument is not necessarily a type; it could 
be any argument that can be inferred by the type checker. 

Coq, Agda, and Idris require all quantification, including that 
for invisible arguments, to be specified by the user. These languages 
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do not support generalization, i.e., automatically determining that 
an expression should quantify over an invisible argument (in addi¬ 
tion to any visible ones). They differ in how they specify the visi¬ 
bility of arguments, yet all of them provide the ability to override 
an invisibility specification and provide such arguments visibly. 

Twelf, on the other hand, supports invisible arguments via gen¬ 
eralization and visible arguments via specification. Although it is 
easy to convert between the two versions, there is no way to visibly 
provide an invisible argument as proposed in this paper. Instead, 
the user must rely on type annotations to control instantiations. 

Predicative, higher-rank type systems As we have already indi¬ 
cated, System B is directly inspired by GHC’s design for higher- 
rank types l23l . However, in this work we have pushed the design 
further, clarifying the treatment of scoped type variables and pro¬ 
viding a declarative specification for the type system. 

Our work is also related to recent work on using a bidirectional 
type system for higher-rank polymorphism by Dunfield and Krish- 
naswami (3, called DK below. There are a few differences between 
the DK system and System B. The most significant difference is 
that the DK system never generalizes. All polymorphic types in 
their system would be considered specified. As a result, their sys¬ 
tem cannot infer prenex polymorphism: a function must have a type 
annotation to be polymorphic. Furthermore, System B includes two 
forms of subsumption. The more flexible relation <dsk requires two 
specified polytypes so is only available at mode switches. DK also 
includes this relation, though a weaker version. However, System 
B also includes implicit subsumption <b, which does not have an 
analogue in the DK system. Instead, the DK system requires an 
“application judgment form” for instantiation. Finally, DK uses a 
different algorithm for type checking than the one proposed in this 
work; though like this paper, it defers instantiations of specified 
polymorphism. An extended comparison with the DK system ap¬ 
pears in Appendix [G| 

Conclusion This work extends the HM type system with visi¬ 
ble type application, while maintaining important properties of that 
system that make it useful for functional programmers. Our exten¬ 
sion is fully backwards compatible with previous versions of GHC. 
It retains the principal types property, leading to robustness during 
refactoring. At the same time, our new systems come with simple, 
compositional specifications. 

While we have incorporated visible type application with all 
existing features of GHC, we do not plan to stop there. In particular, 
we hope that our mix of specified polytypes and type schemes 
will become a basis for additional type system extensions, such as 
impredicative types, type-level lambdas, and dependent types. 
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A. Extended examples using visible types 

In this section we present two longer examples that benefit from 
the addition of visible type application. The second expands and 
explains the code presented in Section[2] 

A.l Deferring constraints to runtime 

Recent work 0 uses the following definition to enable mixing 
static and dynamic typing in order to implement information-flow 
control in Haskell PI 

class Deferrable (c :: Constraint) where 
assume :: V a. Proxy c (c => a) —>■ a 
The parameter to the class Deferrable is a constraint kind - that 
is, the kind classifying constraints that appear to the left of =>. For 
example, Show a is a Constraint. The idea behind Deferrable is 
that, if a constraint is deferred, the program calculates at runtime 
whether or not the constraint holds. 

Let’s consider deferring an equality constraint, written t% ~ T2 
in Haskell. Equality constraints are ordinary constraints; in partic¬ 
ular, they have kind Constraint and can thus be deferred. How¬ 
ever, if we have some type variable a and wish to check if a is, 
say, Bool at runtime, we need runtime type information. Haskell’s 
Typeable feature ITD implements runtime type information. If we 
have a function 

woozle :: Typeable a => a —> a 

then runtime information identifying the type a is available at 
runtime, in the body of woozle. 

Putting this all together, it seems reasonable to defer an equality 
constraint between two types if we have runtime type information 
for both of them: 

instance ( Typeable a, Typeable b) 

=4- Deferrable (a ~ b) where ... 

However, to implement assume, we need one more definition. 

A.1.1 Propositional equality: 

Recent standard libraries shipped with GHC contain the following 
datatype: 

data a :~: b where 

Refl :: a :~: a 

This datatype implements propositional equality. If you have a 
value pf t i T2, that is a proof that types n and T2 are 

equal. Pattern matching on pf reveals this equality to GHC’s type- 
checker, which can then use it in a pattern match: 
boolCast :: (a Bool) -A a -A Bool 
boolCast pf b = case pf of Refl -A- b 

A.1.2 Runtime cast 

The Typeable feature uses :~: in an important function: 

eqT :: (Typeable a, Typeable b) = 4 - Maybe (a :~: b) 

Given runtime type information for a and b, this function condi¬ 
tionally provides a proof that a and b are equal. The eqT function, 
in turn, can be used to implement a runtime cast. 

We are now ready to assemble the pieces: 
instance (Typeable a, Typeable b) 

=4- Deferrable (a ~ b) where 


12 Much of this example - including its use of deferring equality constraints 
- appears in Buiras et al. 0- However, our use of visible type application 
in this example is our own contribution, novel in this paper. 
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assume x = case eqT :: Maybe (a b) of 

Just RefI -4 x 

Nothing —terror" type error!" 

A.1.3 Making assumptions 

Suppose we are working a list type that tracks whether it has surely 
one element, or whether there is an unknown lengthJ^Here are the 
relevant definitions: 

data Flag = Branched — 0 or more elements 
| Unbranched — exactly 1 element 

data List a (b :: Flag ) = ... 
the :: List a Unbranched —> a 
the = ... 

In some places, it is hard to arrange for the type system to ascertain 
that a list is Unbranched, and calling the is impossible. However, 
with Deferrable, we can get around that pesky static type system: 
unsafeThe :: V a b. Typeable b =y List a b —t a 
unsafeThe l 

= assume (Proxy :: Proxy (b ~ Unbranched)) 

(the l) 

The call to assume means that the l is type-checked in an environ¬ 
ment where the constraint b ~ Unbranched is assumed. The call 
the l then type-checks without a problem. 

A.1.4 Deferring errors with visible type application 

This last snippet of code assumes a constraint, and the only way of 
specifying the constraint is via a Proxy. This is what visible type 
application can ameliorate. Let’s rewrite this example with visible 
type application. 

class Deferrable (c :: Constraint) where 
assume :: V a. (c => a) -4 a 
instance (Typeable a, Typeable b) 

Deferrable (a ~ b) where 
assume x = case eqT @a @b of 
Just Refl -4 x 

Nothing -terror" type error!" 
unsafeThe :: V a b. Typeable b => List a b -4 a 
unsafeThe l = assume @(b ~ Unbranched) (the T) 

We have used visible type applications in two places here. One 
is to fix the type of the call to eqT. Because we immediately 
pattern-match on this result, GHC has no way of inferring the types 
at which to use eqT. In the previous version of this example, it was 
necessary to write eqT :: Maybe (a :~: b) here. This annotation 
is noisy, because we care only about the a and the b - the Maybe 
and :~: bits are fixed and add no information. It is easy to imagine 
more complex cases where the noise far outstrips the signal. 

The second use of visible type application is in the definition 
and call of assume, where no Proxy argument is now necessary. 
Once again, this has cleaned up our code and drastically reduced 

Dependently-typed programming with Proxy Dependently- 
typed programming in GHC can require more extensive use of 
proxies. For example, based on Conor McBride’s ICFP 2012 
keynote m, consider a stack-based compiler for a language of 


13 This example is from real code - just such a list is used within GHC when 
keeping track of type family axioms from either open EH or closed (TO) 
type families. 


boolean expressions. (The entire code for this example is available 
in the supplementary material.) 

data Expr :: *where 
Val :: Bool -4 Expr 
Cond :: Expr -4 Expr —» Expr —> Expr 
eval :: Expr —> Bool 
eval (Val n) = n 

eval (Cond eO el e2) = 

if eval eO then eval el else eval e2 

Using standard techniques, we can create a singleton type for 
expressions SExpr and a type-level function Eval that allow the 
type system to talk about these definitions. 

eval :: Expr —> Bool 
eval (Val n) = n 

eval (Cond eO el e2) = if eval eO then eval el else eval e2 
type family Eval (x :: Expr) :: Bool where 
Eval (’Val n) = n Eval (’ 

Cond eO el e2) = If (Eval eO) (Eval el) (Eval e2) 

For example, the evaluator for singleton booleans states that it 
actually calculates the boolean denoted by the expression: 

sEval:: SExpr e -4 SBool (Eval e) 
sEval (SVal n) = n 

sEval (SCond eO el e2) = slf (sEval eO) (sEval el) (sEval e2) 

However, instead of evaluating booleans directly, we would like 
to compile them to a list of instructions for a stack machine. At 
the same time, we would like to know that the resulting list of 
instruction will produce the correct answer when run. 

In other words, given a GADT representing instruction lists, that 
when run will take a stack from its initial configuration to the final 
configuration: 

data Inst ( initial :: [Bool]) ( final:: [Bool]) where 
— Add a value to the top of the stack 
PUSH :: Sing v -4 Inst s (v ’: s) 

— Compare the top value on the stack and branch 
IFPOP :: Listlnst s st -4 Listlnst s sf 
-4 Inst (b ’: s) (If b st sf) 

— a list of instructions, also tracking the machine configurations 
data Listlnst (initial :: [Bool]) (final:: [Bool]) where 

Nil :: Listlnst i i 

(:::) :: Inst i j -4 Listlnst j k -4 Listlnst i k 

infixr 5 ::: 

— concatenate two lists, composing their stacks 
(++) :: Listlnst i j -4 Listlnst j k —> Listlnst i k 
Nil ++ ys = ys 

(x :: : xs) ++ ys = x :: : (xs ++ ys) 

infixr 5 ++ 

We would like to define a compilation function that will create 
a list of instructions that, when run, will put the evaluation of an 
expression at the top of the stack. 

compile :: V (e :: Expr) (s :: [Bool]). 

SExpr e -4 Listlnst s ((Eval e) ’: s) 

The implementation of the compilation function is straightfor¬ 
ward in the case of a singleton boolean value. It just pushes that 
value on the top of an empty stack. 

compile (SVal y) = PUSH y ::: Nil 
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However, the compilation of conditionals runs into difficulties, 
we would like to use this code, which first compiles the scrutinee, 
and then appends the branch instruction. 

compile (SCond seO sel se2) = 
compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 


and supply the type arguments visibly: 

compile (SCond seO (sel :: Sing el) (se2 :: Sing e2)) = 
case fact @(Eval el) @(Eval e2) @s (sEval seO) of 
Refl —> compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 


However, for this code to type check, the compiler needs to 
know the following conversion fact about if expressions 
(If (Eva! eO) (EvaI el) (Eval e2)) vs) 

(If (Eval eO) ((Eval el) ’: vs) ((Eval e2) vs)) 

We can “prove” this fact to the compiler, with a helper lemma, 
called fact below. Note, however that in the result of the lemma, the 
type variables t and f only appear as arguments to the type-level 
function If. Therefore, unification cannot be used to instantiate 
these arguments, so the Proxy type is necessary. 

fact :: V t f s b. Sing b —»• Proxy t —t Proxy f —»• Proxy s 
-> ((If btf)’: s) (If b (t s) (f s)) 

fact STrue _= Refl 

fact SFalse _= Refl 

We can call fact in the case for compile, by providing the 
appropriate Proxy arguments. 

compile (SCond seO (sel :: Sing el) (se2 :: Sing e2)) = 
case fact (sEval seO) (Proxy -.: Proxy (Eval el)) 

(Proxy :: Proxy (Eval e2)) (Proxy :: Proxy s) of 
Refl —t compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

Note, that in our definition of fact above, we have made the 
argument s be specified via Proxy, even though it doesn’t techni¬ 
cally need to to be because it appears outside of the If in the type. 
GHC will also accept this alternative fact ’ that does not include a 
Proxy s argument. 

fact ’ :: V t f s b. Sing b —> Proxy t —> Proxy f 
-> (Cf btf)’: s) (If b (t ’: s) (f s)) 

fact ’STrue _= Refl 

fact ’ SFalse _= Refl 

However, that version of fact is even more difficult to use. Be¬ 
cause the result of fact ’ is used as the argument of GADT pattern 
matching, GHC cannot use unification to resolve type variables in 
this type. Instead, to make this code type check, we require an even 
more extensive type annotation: 

compile (SCond (seO :: Sing eO) 

(sel :: Sing el) (se2 :: Sing e2)) = 
case (fact ’(sEval seO) 

(Proxy :: Proxy (Eval el)) 

(Proxy Proxy (Eval e2)) :: 

((If (Eval eO) (Eval el) (Eval e2)) ’: s) 

(If (Eval eO) ((Eval el) ’: s) ((Eval e2) ’: s))) of 
Refl —b compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

In the presence of visible type application, we would like to 
avoid the proxies all together: 

fact :: V t f s b. Sing b —► 

((If btf)’: S) :~: (If b (t ’: S) (f ’: s)) 
fact STrue = Refl 
fact SFalse = Refl 


B. Properties of System HMV 

Lemma 10 (Inversion for <hmv ). 01 <hmv 02 if and only 
if ax = V{oi}, 62, b\. Ti and 03 «* V{a 2 }, 62-72 where 
ti\t\/~& x]]fifb. = r 2 . 

Proof. By unfolding definitions. □ 

Lemma 11 (Reflexivity for <h mv ). Forall a, a <hmv 0 
Proof. By definition. □ 

Lemma 12 (Transitivity for <hmv). If <jx <hmv 02 and 02 <hm» 
03, then 01 <hmv 03. 

Proof. Let 03 = Vjcis}, bs,. T3. Then, by inversion, we know 
02 = V{a2}, 63, &2.T2 and T2[r2/a2][T2/&2] = 13. We further 
know 01 = V{ai}, 63, 62, hi-Ti and Ti[ri/ai][r'i/6i] = r 2 . 
Thus, n|ri/0i][ri/6i][r2/'02][r2/62] = T3. By the Baren- 

dregt convention, we know that 0,2 do not appear in n. Thus 
we can rewrite as n [ri[r 2 /a]/ai][r'i [r2/a 2 ]/6i] [T2/&2] = r 3 . 
This is enough to finish the derivation via HMV_InstS and 
HMV_InstG. □ 

Lemma 13 (Substitution in <hmv). 

1. Ifvi <hm U V2, thenvi[r/a] <hmv w 2 [r/a]. 

2. If ax <hmv 02, ffen0i[r/a] <hmv 0 2 [r/a]. 

Proof. Immediate. □ 

Lemma 14 (Context Generalization for HMV). If T h, mv e : 0 and 
T' <hmv I\ then T' in,™, e : 0. 

Proof. This is by straightforward induction, with an appeal to 
HMV_Sub in the variable case (HMV_Var). □ 

Proof of Lemma^l Extra knowledge). This is a corollary of con¬ 
texts generalization as V{if}. r <hmv Vo. t. □ 

C. Proofs about System V 

Proof of Soundness of V against HMV (Theorem^. By induction 
on the appropriate derivation. Most cases follow directly via in¬ 
duction. 

Case V_InstS This case follows via induction and HMV_Sub 
using the fact that Vd. r <hmv r[r/a] by HMV_InstS. 

Case V_Var This case follows via HMV_Var and HMV_Sub 
using the fact that V{a}. r <hmv r[r/a] by HMV_InstG. 

□ 

Lemma 15 (Context generalization for V). 

1. If T e : v and T' <hmv T, then there exists v' such that 
T'^ e:v' and v' <hmv v. 

2. IfF hj e : t and V < hm v T, then T' ^7 e : r 

3. If T \^ en e \ 0 and T' <h m v r, then there exists a' such that 
r' \^ n e : a' and a' < hmv 0. 
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In all cases, the size of resulting derivation is no larger than the a is free in neither v nor F: In this case the substitution has no 
size of the input derivation. effect and we are done. 


Proof By induction on derivations. Most cases are straightforward; 
we present the most illuminating cases below: 


Case V_Var: 


r £ X : v[T/a\ 


V_Var 


Given £:V{a' }.v' € T' where V{a'}.u' <h mv V{a}.w, we 
must choose r' such that w , [t , /'o'] <h m , u[t/o]. Inverting 
<hmv gives us that v'[ t'/ a] <hmv v. We are thus done by 
Lemma[l3l Note that the size of both derivations is 1. 

Case V_TApp: 


t closed r f e : Vo. v 
r f e @t : v[t/ a] 


V_TAPP 


The induction hypothesis gives us T' f e : v' where v' <hmv 
Vo. v. By the definition of <hmv » v ' must also be quantified 
over a. We can thus reduce to Va. v" <hmv Vo. v, which 
reduces to v" <hmv v. We must prove that v"[t/cl\ <hmv 
v[t/ a], which follows directly from v" <h m « v via Lemma[l3| 
and so we are done. 

Case V_Gen: 


d = ftv(v)\ftv(?) r^e-.v 
r f “ e : V{o}. v 


V_Gen 


The induction hypothesis gives us T' f e : v' where v' <hmv 
v. By inversion, we know that v' = Va', b . n and v = Vo'. t 2 
where ti[t'/6 ] = r 2 . 

Let a = ftv(y)\ftv(T) and 6 = ftv(v')\ftv(T'). We want to 
show that V{6}. v' <hmv V{o}. v. Expanding out, we want to 
show that V{6}, o', b . n <hmv V{o}, o'. r 2 , where ri|r/6| is* 
r 2 . Unfolding <hmv shows that we want n [t/6] pfi'/6 ] = r 2 . 
Choose T = b and we are done. 


□ 


Lemma 16 (Substitution for V). 

1. IfTk e: t', then r[r/o] [77 e : t'[t/o\. 

2. IfT f e : v, then V[t/o\ £ e : v[r/a}. 

3. 7/r If" e : (7, then r[r/o] tf n e : tr[r/o]. 

Proof. By induction, frequently using the Barendregt convention to 
rename bound variables to avoid coinciding with free variables. 

The interesting case is generalization: The premise of this case 
is T If e : v where o = V{6}. v for 6 = ftv(v) \ ftv(T). By the 
Barendregt convention, note that b do not contain a. 

The induction hypothesis gives us r[r/o] f e : v[t/ a]. Let 
c = ftv(v[r/a]) \ ftv(r[r/a]). To use V_Gen to conclude 
T \% en e : (V{c}.w)[r/o], we must show that b = c and that 

We now have several cases: 

a is free in both v and in T: In this case fiv (v[t/ o]) includes the 
free type variables of v, minus a, plus the free variables of r. 
Likewise, ftv(T[r/a]) includes ftv(F), minus a, plus the free 
variables of r. In each case, the sets that produce c are changed 
by the same variables. Therefore, b and c must be equal. 
a is free in v but not free in T : To be in this case a must be in 6, 
which cannot happen. 

a is not free in v but is free in F: In this case 6=1 and we are 
easily done. 


□ 


Proof of Completeness (Theorem^. We proceed by induction on 
r fimv e : a. 


Case HMV_Var: Straightforward, using the types a to instanti¬ 
ate the variables o in V_Var. We know these a are not free 
in r by the Barendregt convention. It may be the case that 
generalization quantifies over more variables, i.e. o C o' = 
ftv(v) \ ftv(T), leading to a more general result type. How¬ 
ever, that is permitted by the statement of the theorem. 

Case HMV_Abs: 


T, a::ri e : r 2 
T htmv As. e : n -A T 2 


HMV_ABS 


The induction hypothesis gives us F, x:ti If™ e : V{o}, 6. r 2 
where t 2 = T 2 [ ; r'/6][r/a]. Inverting if™ gives us r,s:n if 
e : V6 .t 2 . We can then use V_InstS and V_Abs to get 
T i^ As. e : n —t t 2 [t'/ 6]. Generalizing, we get T if™ 
As. e : V{a, a'}. t\ -a t 2 [t'/ 6] where the new variables 
o' come from generalizing n and the r'. We can see that 
(n -a_ r 2 ['t - "'/ 6] ){t/o] = n -¥ r 2 and so V{a, o'j.n -¥ 
r 2 [r'/6] <hmv ti —> T 2 and we are done. 

Case HMV_App: 


r htmv Cl : n - 


r i^mv e 2 : n 


The induction hypothesis gives us T f en ei : 
V{oi}, 61. Til -y T12 withri = rii[ri/oi][r'i/6i] andr 2 = 
Ti2[ i ri/ai][r'i/6i], along with T if™ e 2 : V{a 2 }, 6 2 .r 2 i with 
n = r 2 i[r 2 /a 2 ][ri/6 2 ]. Inverting if™ gives us T If ei : 
V61.T11 —t T12 and T if e 2 : V6 2 .r 2 i. 

We now use the Substitution Lemma (Lemma EH with the 
substitution [ri/oi] on the first of these to yield T f ei : 
V61 . th[ti/oi] —t r i2 [ri/oi]. Note that the ai must not be 
free in T, by inversion of f cn . Similarly, Lemma ph| gives us 
r f e 2 : V6 2 .t 2 i[t 2 /o 2 ]. 

We can then use V_InstS on both of these judgments, to 
show r ei : ni[ri/ai][ri/6i] ri2[ri/oi][r'i/6i] and 
r f e 2 : r 2 i [r 2 / 0 2 j [r 2 / 6 2 ]. 

We can now now use V_App, as the argument type is equal to 
Ti , established earlier. Rule V_App then gives us T ei e 2 : 
n2[Ti/oi][r'i/6i]. This type, as noted earlier, equals r 2 , and 
so we are done. 

Case HMV_Int 


r bimv 


Trivial. 

Case HMV_TApp: 


: Int 


HMV_lNT 


r closed T i^ mv e : Va. v 
r bt™ e @t : v\T/a] 


HMV_TAPP 


The induction hypothesis (after inverting if 6 ’") gives us T f e : 
Vo.w', where 6 = ftv(Wa.v') \ftv( T) and w'[r/6] <hmv 
v. Applying V_TAPP gives us T f e @r : u'[r/a], 
and V_Gen gives us T f™ e @t : V{c}. v'[r/a] 

where c = ftv(v'[T/a\) \ ftv(T). We want to show that 
V{c}. v'[r/a] <hmv v[t/ a], which follows when there is some 
r', such that u'[r/o] [r'/c] < hm „ v[t/o\. 

This is equivalent to exchanging the substitution, i.e. finding a 
r' such that u'[r'/c][r/a] < hm v v[r/a]. 
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By Substitution (Lemma |~i~3}, we have u'[r/6][r/a] <hmv 
v[t/ a]. We also know that the 6 are a subset of the c. So we 
can choose r' to be t for the b, and the remaining c elsewhere, 
and we are done. 

Case HMV_Let: 


r fc mv ei : o-j r, x:oi fc mv e 2 : cr 2 
T let x = ei in e2 : (72 


HMV_LET 


The induction hypothesis gives us T \% en ei : a\ with a\ <hmv 
err. The induction hypothesis al so g ives us T, x:o\ e 2 : (72 
with (72 <hmv (72. Use Lemma [l5jto get T, x\a\ ^ Kn e 2 : <j 2 
where a 2 <hmv_CT 2 - 

Let (72 = V{6}.t> where b = ftv(v) \ ftv(T). Inverting 
\f' n gives us T. x/.o\ 1^ e 2 : v. We then use V_Let to get 
T let x = ei in e 2 : v. Generalizing gives us T \^ en let x = 
ei in e 2 : V{6}. v. 

Transitivity of <hmv (Lemma[l2J gives us V{6}. v <hmv cr 2 . 

Case HMV_Annot: 


v closed v m Va. r T lj; mv e : t 
r (e:v):v 


HMV_Annot 


The induction hypothesis gives us T \^ en 
r'[r/6][r'/6 ] = r. Inverting gives 
Applying V_InstS gives us T ^ e : 
V_Annot to be done. 

Case HMV_lNT: Trivial. 

Case HMV_Gen: 


e : V{6}, b'. t' with 
us T ^ e : Vb'. t'. 


r L,e:(r a<£ftv(Y) 

T^ mv e:V{a}.(7 


HMV_Gen 


The induction hypothesis gives us T \^' m e : o' where o' <hm» 
cr. Weknowa' <hmv V{a}. a. In other words, if o' = V{6}. v\ 
and cr = V{c}. vi, we have some r such that vi [r/b] = vi. 
By the definition of <hmv we can use these same r to show that 
(7' < hm „V{«,c}. W2 . 

Case HMV_Sub: 


T fr; mv e : (71 (7l <hmv (72 

r bi mv e : (72 


HMV_SUB 


The induction hypothesis gives us T \^' m e : a' where cr' <hmv 
(7i. By transitivity of <hmv, we are done. 


□ 


D. Algorithm V 

In this appendix, we use metavariables Q, R, and S to refer to 
substitutions from type variables a to monotypes r. We apply 
and compose these as functions, homomorphically lifted from type 
variables to types. 

We suppose the existence of a unification algorithm U, that 
produces a substitution S, with the following properties 

• If S = Ua(ri,T 2 ) then either S(ti) = S(t 2 ) and a fl 
dom(S) = 0, or no such S exists. 

• If R(ti) = R{ti) (and a fl dom(R) = 0) then there exists 
some S such that R = S o (f u (n , 72 ). In other words, unifica¬ 
tion produces the most general unifier. 

With this function, we can define three mutually recursive, par¬ 
tial functions that infer the type of an expression in a given context. 
These equations are to be read top-to-bottom. 


Definition 17 (Algorithm V). 

(1) V(r, Xx. e) = (Si, Si(b ) -!• r) when 

V((V,x:b),e) = (S 1 ,r) 

(2) V(r, ei e 2 ) = ( S 3 o S 2 o Si, S 3 (b)) when 

(Si,n) = V(r, ei) 

(£ 2 , 7 - 2 ) = V(Si(r),e 2 ) 

Ss = M(4(n),is-H) 

(3) V(r, n) = (e, Int ) 

(4) V(r, e) = (Si,t) when 

(Si,Vd. t) = V*(T,e) 


(5) V*(r, x ) = (e, v) when 

z:V{a}. v 6 T 

(6) V*(r, let a; = ei in e 2 | m (S 2 ° Si,v 2 ) when 

(Si,(7i) = V 9 erl (r, ei) 

(S 2 ,v 2 ) = V*((£i(r),xicri), e 2 ) 

(7) V*(r, e @r) = (£i,vi[r/a]) when 

(Si, Va. ui) = V*(T, e) 

(8) V*(r, (e : v)) = (£2 o Si,w) when 

v closed 

(£i',rO = V(r, e) 

£2 = Ua(T,T') 

(9) V*(T, e) = V(T, e) 


(10) V 9 m (r, e) = (£, V{a}. u) when 
(£,«)= V*(T, e) 

a = ftv(v)\ftv(m) 


Lemma 18 (Soundness of Algorithm V). 

1. If V(T, e) = (£, r) then £(T) ^ e : r 

2. //V*(r, e) = (£, v) then £(T) ^ e : v 

3. IfV gen (r, e) = (£, a) then S(T) % en e : a 


Proof. By mutual induction on the structure of e. In the text of the 
proof, we will proceed in order of the clauses in the statement of 
the lemma, though technically, we should be considering the shape 
of e as the outer-level structure. 

1. Case e = Xx. e: By (1), we have V(I\ Xx. e) = 
(Si, Si( 6 ) -A r), where (Si, r) = V((T, x:b), e) and 
b is fresh. We must show Si(T) k Xx. e : £ 1 ( 6 ) -»• t. The 
induction hypothesis tells us £1 (T. xx.b) h; e : r. Rewrite 
this as £i(r), x:Si(b) k e : t. V_Abs then gives us the 
desired result. 

Case e = ei e 2 : By (2), we have V(T, ei e 2 ) = (£3 o S 2 o 
£ 1 , £ 3 ( 6 )), with several side conditions from the statement 
of V. Let R = S 30 S 2 o Si. We must show /J(T) ei e 2 \ 
S 3 (b). The induction hypothesis gives us £i(r) ei : n 
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and ft (ft (r)) (7 e 2 : T 2 . Furthermore, we know that 
ft(&(n)) = S 3 (t 2 -a 6). 

By the substitution lemma (Lemma |T6j, we know that 
R(T) k ci : ft(&(n)) and R(T) fTe 2 : ft(r 2 ). The 
first of these can be rewritten to R(F) ^ ei : S 3 (t 2 -a 6 ), 
or R(T) k ei : ft(r 2 ) -A ft ( 6 ). We now use V_App to 
get J?(r) ^ ei e 2 : S 3 (b) as desired. 

Case e = n: By (3), we have V(r, n) = (t, Int). We must 
prove r^n : Int, which we get from V_lNT. 

Other cases: By (4), we have V(T, e) = (ft, r), where 
(ft, Va. t) = V*(r, e). By the induction hypothesis, we 
have ft(F) If e : Va.r. By V_InstS, we have ft(r) Iv 
e : r[r/a] for our choice of r. Choose r = a and we are 

2. Case e = x: By (5), we know V*(r, x) = (e,v) where 

x:V{a}.w S T. We must show F if x : v. This is direct 
from V_VAR, choosing r = a. 

Case e = let a; = ei in e 2 : By (6), we know V*(r, lets = 
ei in e 2 ) = (ft o ft,w 2 ) where (ft,cn) = V 9en (T, ei) 
and (ft,« 2 ) = V*((ft(F), x:oi), e 2 ). We must show 
ft(ft(r)) Sp' let a; = ei in e 2 : v 2 . The induc¬ 
tion hypothesis gives us Si (T) If™ ei : 01 and 

S 2 (Si(r),x:ai) If e 2 : v 2 . Substitution on the former 
gives us ft(ft(r)) If™ ei : ft(cri) and we can rewrite 
the latter as ft(ft(r)), x:S 2 (ai) If e 2 : v 2 . V_Let gives 
us our desired result. 

Case e = eo @r: By (7), we know V*(r, eo@r) m 
(Si, Ui[r/6]) ■where (&,Va.ui) = V*(r, e). We must 
show S’i(r) If eo @r : Vi[r/b]. The induction hypothesis 
gives us Si (r) If eo : Va. Vi, and we are done by V_TApp. 

Case e = (e 0 : v): By ( 8 ), we know V*(r, (eo : v)) = 
(S 2 o Si,v) with side conditions from the statement of 
V, including Va. r = v. We must show S 2 (Si(r)) If 
(eo : v) : v. The induction hypothesis gives us ft (T) Iv 
e : t' and we also know S 2 (r) = ft(-r'). Substitution 
(Lemma [1^ gives us ft (ft (r))Vfej,e : S 2 (r'), which 
can be rewritten as ft(ft(T)) (7 e : ft(r). We know 
that v is closed, which means that JIv(t) C a. However, 
a IT dom(S 2 ) = 0, so &(t) = r. We thus can use 
V_Annot and we are done. 

Other cases: By (9), we have V*(r, e) = (ft r) where 
(ft r) = V(r, e). We must show S(T) If e : r. The 
induction hypothesis gives us S (T) 1 7 e : r. We are done 
by V_Mono. 

3. All cases: By (10), we know V 9 ™(r, e) = (ftV{a}.u) 

where (S, v) = V*(r,e)anda = ftv(v)\ftv(S(F)).We 
must show S(T) If™ e : V{a}. v. The induction hypothesis 
gives us S(T) If e : v, and we are done by V_Gen. 

□ 

Lemma 19 (Substitution/generalization). If a = ftv(v)\ ftv(T) 
andb = ftv(S(v)) \ ftv(S(T)), then S(\/{d}.v) < hmv 
V{b}.S(v) 

Proof. We must show »S'(V{a}. v) <hmv V{6}. S(v). Simplify 
this to V{c}. ftpfe/a]) <hmv V{6}. S(v) where the c are fresh. 
(They are used to implement capture-avoidance.) By the definition 
of <hmv (HMV_InstG), this simplifies to S'(w[c/o])[r/c] <hmv 
S(v), for our choice of t. Choose r = S(a), yielding our wanted 
to be S'(u[c/a])[yS'(a)/e] <hm« S(v). Simplifying again yields 
S(v[c/d][d/c\) < hmv S(v), which is the same as S(v) < hmv 
S(v). We are done by reflexivity of <hmv . □ 


Lemma 20 (Completeness of Algorithm V). For all contexts T and 
substitutions Q: 

1. If Q( r) kj e : r, then V(r, e) = ( S,t') and there exists R 
such that Q = R o S and r = R(t'). 

2. If Q(T) If e : v, then V*(r, e) = (ft v') and there exists R 
such that Q = R o S and v = R(v'). 

3. If Q(T) If™ e : cr, then V 9en (r, e) = (ft o') and there exists 
R such that Q = R o S and R(o’) <hmv o. 

In the Q = R o S conclusions above, we ignore any differences on 
type variables that are conjured up as fresh during recursive calls. 


Proof. We proceed by mutual induction on typing derivations. In 
each case, we must provide the following pieces: 

(i) The result of the call to V (such as (ft r')) 

(ii) The substitution R 

(iii) The fact that Q = R o S 

(iv) The fact that, say, r = R(r') 

These pieces will be labeled in each case. 


r ^ \x. t 


V_Abs 


We know that <9(r), x:n k e : t 2 . Let T' m .ft x:b (where 
b is fresh) and Q' = [ri/6] o Q. Then, we can see that 
Q'(T') k e : r 2 . We thus use the induction hypothesis to get 
V((r,s:&),e) = (£, 7 - 2 ) along with R’ such that Q’ = R’oS 
andr 2 = R' (rf). We can thus see that 

(i) V(ftAx.e) = (ft 5(6) -► 7^). 

We have left only to provide R such that Q — R o S and 
Ti-r t 2 = R(S(b) —t -ft = R(S(b)) —y R(tZ). 

(ii) Choose R= R'. 

By functional extensionality, Q = R' o S iff Q applied to any 
argument is the same as R' o S applied to any argument. But 
in our supposition that b is fresh, b is outside the domain of 
possible arguments to Q; thus we can conclude 

(iii) Q = Q' = R' o ft ignoring the fresh b. 

(iv) We can also see that n = Q'(b) by definition of Q' and 
that t 2 =■ R(t 2 ) by the use of the induction hypothesis. 

Case V_App: 


r k ei : n ->• r 2 r k e 2 : n 


V_APP 


The induction hypothesis tells us that V(T, ei) = (ft,r() 
with R\ such that Q = ft o Si and n —>■ t 2 = R] (ft). 
Recall that we are assuming Q(T) hj ei e 2 : r 2 , which can 
now be written as ft(ft( Q)) k ei e 2 : r 2 . We thus know (by 
inversion) ft (Si ( Q)) (7 e 2 : n. We then use the induction 
hypothesis on this fact, but choosing Q be ft, not the Q 
originally used. This use of the induction hypothesis gives us 
V(ft( Q), e 2 ) = (ft, t 2 ) with R 2 such that ft = ft o ft 
and n = ft(r 2 ). We now must find a substitution S 3 that is 
a unifier of & (r[) and t 2 -a b for some fresh b. We know 
Ri(t[) = Ti — ¥ t 2 and R 2 (tZ) = n. We can rewrite the 
former as ft(ft(r()) — %*—> r 2 . Choose ft = [r 2 /b] o ft. 
We see that ft (ft (ft)) = ft (ft -A b) as required. We 
now know that U (ft (ft), ft —y b) will succeed with the most 
general unifier ft. We thus know that 

(i) V(r, ci ca) = (ft o ft o Si, S 3 (b)). 

We must now find R. By the fact that ft is a most general 
unifier, we know that ft = R o ft. 

(ii) Choose R to be this substitution, found my the most- 
general-unifier property. 
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(iii) Putting all the facts about substitutions together, we see that 
R o S3 o S 2 o 5i = Q as needed (ignoring the action on the 
fresh b). 

We must finally show T 2 = R(Ss(b)) = S^b). 

(iv) This comes from the definition of S3. 

We are done. 

Case V_Int: 


(i) V(T,n) = (e, Int). 

(ii) Choose R= Q. 

(iii) Q = Roe, quite easily. 

(iv) Q(lnt) sure does equal Int. 
Case V_InstS: 


rf e : Vo.r 
no other rule matches 


Tke: r[r/a] 


V_InstS 


The induction hypothesis gives us V*(T, e) = ( S,Va.r') 
with R' such that Q = R' o S and R’(Wa. r') = Vo. r. Note 
that we have liberally renamed bound variables here to ensure 
that the quantified variables a are the same in both cases. This 
is surely possible because the substitution R' cannot change the 
number of quantified variables (noting that t' must not have any 
quantified variables itself). We thus know iZ'(r') = rand that 
a fl dom(R') = 0. 

(i) We can see that V(T, e) = (, S,r '). 

(ii) Choose R to be the [t/o] o R’. 

(iii) We can see that Q = RoS as required (ignoring the action 
on the fresh a). 

We have already established that R'(r') = r. We must show 
that R(r') = r [t/o]. 

(iv) This follows from our definition of R. 

We are done. 

Case V_Var: 


x:V{a}.r;€r 

r^: W [r/a] 


V_Var 


We know .x:V{a}. v € <2(T). Thus, there exists v such that 
x:V{ffl}.«' € T where Q(v') = v. 

(i) Thus, V*(T, x) = ( e,v '). 

(ii) Choose R = [r/o] o Q. 

(iii) Clearly, Q = Roe, ignoring the action on the fresh a. 
We must now show that R(v') = u[t/o]. 

(iv) This is true by construction of R. 

Case V_Let: 


r if* ei : cri V, x:eri % e 2 : v 2 

r I* let X = ei in e 2 : v 2 


V_Let 


The induction hypothesis gives us V'' en (r, ei) = (Si, a\ ) 
with R] such that Q = Ri o Si and Ri(a[) <hmv cri. 
We know (from inversion) that /?i (Si (r)), ncn tj e 2 : v 2 . 
We also see that Ri(Si(T), xt^) < hmv tfi(Si(r)), x-.a x 
and thus that Ri (Si(T), x:o \) if e 2 : v 2 , by context gen¬ 
eralization (Lemma [15] >, which preserves heights of deriva¬ 
tions. We thus use the induction hypothesis again to get 
V*((Si(r), x:cr[), e 2 ) = (S 2 ,v 2 ) with R 2 such that Ri = 
R 2 o S 2 and v 2 = R 2 (v 2 ). 

(i) We thus have V*(T, let x = ei in e 2 ) = ( S 2 o Si,v 2 ). 

(ii) Choose R = R 2 . 

(iii) We can see that Q = R 2 o S 2 o Si as desired. 

(iv) We can further see that R 2 (v 2 ) = v 2 as desired. 

Case V_TApp: 


t closed T hj e : Vo. v 
T £ e @r : v[t/ a] 


V_TAPP 


The induction hypothesis gives us V*(I\ e) = (S, v') with 
R' such that Q — R' o S and Va. v = R'(n'). Because 
the substitution R' maps type variables only to monotypes, we 
know v' must be Vo. v", with R'(v") = w and a 0 dom(R'). 

(i) We thus know V* (T, e @t) = (S, v"[t/o\). 

(ii) Choose R = R'. 

(iii) We already know Q = R' o S. 

We must show 7?'(w"[r/o]) = v[r/a]. This can be reduced 
to R'iy") [i?'(r)/o] = v[r/a] by the fact that a & dom(R). 
Furthermore, we know r is closed, so we can further reduce to 
R'(v")[r/a) = v[r/a], 

(iv) But we know R'(v") = v, so we are done. 

Case V_Annot: 


v closed v = Vo. r Jf.lp e : r 

r (e :v) :v 


V_Annot 


The induction hypothesis gives us V(T, e) = (Si,t') with 
Ri such that Q = Ri o Si and Ri(t') = r. We must 
show that r and r' have a unifier. We can assume (by the 
Barendregt convention) that ofl dom(Ri) = 0. We also know 
that ftv (r) C a. Thus, Ri (r) = r and R\ is a unifier of r and 
r'. Let S 2 = Ua(r, r') (which is now sure to exist). 

(i) We thus have V*(T, (e : v)) = (S 2 o Si, v). 

(ii) Choose R as determined by the fact that Ri — R o S 2 
(gained from the most-general-unifier property). 

(iii) We thus see that Q = R o S 2 o Si as desired. 

(iv) Furthermore, by the fact that v is closed, we get R(v) = v, 
as desired. 

Case V_Mono: 


r^e:r 

no other rule matches 
-—- V_Mono 

The induction hypothesis gives us V(r, e) = ( S , r') with R 
such that Q = Ro S and R{t') = r. 

(i) We see that V* (T, e) = (S,r'). 

(ii) Choose R to be the one we got from the induction hypothe- 

(iii) We see that Q = RoS. 

(iv) We see that fl(r') = r. 

Case V_Gen: 


a=Mv)\M?) R^e-.v 

rtf" e : V{a}. v 


V_Gen 


The induction hypothesis gives us V*(T, e) = (S, v') with 
R such that Q = R o S and R(v') = v. We know a = 
ftv(R(v'))\ftv(R(S(T))'), and let o' = T)). 

(i) We see that V 9 cn (r, e) = {S, V{o'}. v'). 

(ii) Choose R as from the induction hypothesis. 

(iii) We know Q = RoS. 

We must show i?(V{a'}. v') <h mv V{a}. v 

(iv) This is direct from Lemma[T9l 


□ 


Proof of principal types for HMV (Theorem^. By completeness 
of V (Theorem [ 5 ), we have a' 0 such that T tf eTi e : on and 
o0 <hmv cr. By completeness of Algorithm V (Lemma |20), we 
have V 9cn (T, e) = {S,a' p ) with R such that e = R o S and 
R(cr p) <hmv cro-Leto-p = -R(cTp). By the soundness of Algorithm 
V (Lemma [18), we know that 5(r) t/ er ‘ e : a' p , or equivalently: 
S(T) eTS(a p ). By substitution, we can substitute through by 
R to get T \^ en e : cr p . By soundness of V (Theorem [5j, we have 
T l^mv e : cr p . Recall that o p <h m « cr 0 . But we assumed nothing 
about 00. Thus, cr p is a principal type for e. ''ftp 
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:know that o\ is V{6}, a, c. 0 i 


| cri <b <72~| Higher-rank instantiation 

—— B_Refl 


Vi -A V2 <b V3 —f Va 


B_Fun 


V 5 , 6. 01 <b Vo. 02 
wi [r/o] <b«2 6 0 /tw(V{a}. wi) 


V{o}.t 


b V{6}. i 


Figure 13. Inner instantiation 


Proof of decidability of System V (Theorem^. All that remains is 
to show that Algorithm V terminates. All cases in Algorithm V 
except for cases ( 4 ), ( 9 ), and ( 10 ) recur on a structural component 
of the input. We can observe that ( 4 ) and ( 9 ) cannot infinitely recur, 
because one of the other cases is guaranteed to intervene. Because 
( 10 ) recurs from V 3en (r, e) to V*(I\ e), it, too cannot loop. Q 

E. Higher-rank systems: properties of <b 

This section concerns the properties of the first order subsumption, 
higher-order instantiation relation, oi <b <72. For reference this 
relation is repeated in Figure [ 73 ] 

Lemma 21 (Monotypes are already instantiated). Ifn <b T2 then 
Tl = T2. 


Proof By inversion. □ 

Lemma 22 (Substitution for instantiation). If oi <b <72 then 
S(ot) <b S(<r 2 ). 

Lemma 23 (Reflexivity for <b ). For all cr, a <b cr. 

Lemma 24 (Transitivity for <b ). If cr\ <b 02 and 02 <b cr 3 , 
then cri <b <73. 


Proof Proof is by induction on H(ct 2), where the H function is 
defined as follows: 


H(r) 
H(v 1 - > v 2 ) 


H(Va. 0 ) 
^(V{a}.«) 


l + max{Hvi,Hv 2 ) 
when at least one of vi and 1)2 
is not a monotype 
1 + #( 0 ) 

1 + H(v) 


Note that the H function is stable under substitution (replacing 
variables by monotypes). 


Case (72 is r, a monotype In this case, by Lemma [ 31 ] we know 
that 03 must also be r. So the result holds by assumption. 

Case (72 is V21 —> V22 By inversion, we know that cri is 
V{o}, 6,c. un -A V12 such that U21 <b vn[r/a,c] and 
ui2[r/a, c] < b U12. 

We also know that 173 is V{d}. U31 —} V32, such that vs 1 <b 
W21 and V22 <b V32- 

By induction, we can show V31 <b i;ii[f/o,c] and 

U 12 [t/ 0 ,c] <b U 32 . 

This lets us conclude that cri <b (72. 


Case (72 is Va. 0 2 By inversion, we 
such that 0i [r/6,c] <b 02. 

We also know that 03 is V{d},^i. 03 where a = 'ai, ffl2 and 
02 <b 03 - 

By substitution, we can show that 0 i[r/ 6 ,c][t'/ a2] <b 
02 [ 7 = 702 ]. 

By induction, we then have 0 i[t/ 6 , c] [7=702] <b 03 - We can 
then derive cri <b (73 to conclude. 

Case (72 is V{fi}. V2 By inversion, we know that cri is V{ 6 }. Vi 
where vi[r/ 6 ] <b V2. 

We also know that 03 is V{c}. V3, where V2 [ 7 = 7 «] <b "^3. 

By substitution, we can show that v\\r/b]\r'/d\ <b /a]. 

Rewrite this as vi[r[r 7 o]/ 6 ] <b vrff'/d\. 

By induction, we have Vt J j'/'&}/b] <b V3. 

Therefore we can conclude V{6}. vi <b U3. 


□ 


F. Higher-rank systems: properties of DSK 
System B 

This section considers the Higher-Rank type systems with deep- 
skolemization, described in Section[6] 

F.l Properties of Prenex conversion 

Lemma 25 (Instantiation and Prenex). If v <b v' and 
prenex(v) = V a. p and prenex(v 1 ) = 'ib.p', thenWa.p <b 
V6. p' and b Ca. 


Proof. Proof is by induction on v <b v'. 


Case B_InstS: 

01 [t/ 6] < b 02 

Vo, 6. 0 i <b Va. 02 


B_InstS 


Say that prenex(v) = Va,b,c.p , 1 where prenex{4>) = 
Vc.pi. 

This means that prenex((j>\ [t/ 6 ]) = Vc. p\\f/T)\ as 7= do not 
contain quantifiers. 

Say also that prenex(v') = Va, d. 0 2 where prenex(4>2) = 
Vd. p2. _ _ 

By induction, we have that p\ [t/ 6 ] <b p'2 where d C c. 
Therefore we can conclude by B_InstS that 
Yd. p[ <b V 6 . p' 2 
Case B_Fun: 


V3 <b v\ V2 <b Va 
Va -> v 2 <b v 3 —> v 4 


B_FUN 


Note that prenex(vi —¥ V2) = Va.v 1 —¥ P2 where Vo. p2 = 
prenex(v 2) and the a are not free in vi. prenex(V3 —^va) = 
V6. U 3 —y Pa where V6. p 4 = prenex(v 4 ). So by induction, we 
have that Va. P2 <b V6. p 4 and 6 C o. 

By inversion, we have that p2 [7/0] <b Pa. From this we can 
derive v\ ->• p2 [r/a] <b u.3 Pa and then Va. v\ -t p2 <b 
V6.U3 —t Pa- 
Case B_Refl: trivial. 


□ 

Lemma 26 (Prenex instantiates). If prenex(v) = Vo. p then 
v <b P- 

Proof Proof is by induction on v. If v is a monotype, we are done. 
If v = Vi —> V2, then prenex(v) = Va.v 1 —> p2 where 
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prenex(i>2) = Va. pi- By induction, we know that vi <b p, so 
by B_Fun, we have v\ — y vi <b Vi —y p. 

If v is a specified polytype, of the form Va. 0, then 
prenex(v 2 ) « Va, 6 . p' 2 where prenex(<j>) = V 6 . p 2 . By induc¬ 
tion, we know that pi <b p 2 - We can then show that Va, b. pi <b 
pi by B_InstS (and instantiating variables with themselves.) .10 

F.2 Properties of DSK subsumption 

Lemma 27 (Substitution for higher-rank subsumption). Ifv 1 <d s k 
v 2 then S(vi) <dsk S(v 2 ). Ifcn <dsk v 2 then 5(ci) <dsk S(v 2 ). 

See Vytiniotis et al. (26) Lemma 2.7. 

Lemma 28 (Reflexivity for <d S k ). For all v, v <d S k v. 

Proof. Vytiniotis et al., |26) Lemma 2.21. D 

Lemma 29 (Transitivity for <d s k ). Ifv 1 <dsk v 2 and v 2 <dsk V3, 
then vi <dsk V3. 

Proof Vytiniotis et al., |26) Lemma 2.22. □ 


Lemma 30 (Single skol admissible). If cr 1 <dsk v 2 then 01 <dsk 
Vc. v 2 (when c are not free in a\). 


Proof Proof is by induction on eri <dsk v 2 . 


Case DSK_Refl: Direct by DSK_InstS. 
Case DSK_Fun: 


- dsk P4 DSK_Fun 

I ->• P4 


Case OL_B_AFUN: By induction. 

Case OL_B_AInstS: 

0i[t/o] <oi 02 6 0 ftviffd. 0 i) 

Va. 0i < 0 i V 6 . 02 


OL_B_AInstS 


By induction we know that 0i [r/ 6 ] <d s k 02- We want to show 
that Va. 0i <dsk V 6 . 02. Say prenex{<f>2) = Vc. P2, then by 
DSK_Inst it suffices to show that 0i [t'/ 6] <dsk P2. Note that 
as Vc. p 2 <dsk P2, by transitivity, we can reduce this to showing 
0 i[ t/ 6 ] <dsk prenex(4> 2 ). 

We can finish, again by transitivity, by showing via Lemma[32] 
that 02 <dsk prenex(cj ) 2 ). 


□ 


Corollary 34 (DSK Subsumption contains Instantiation). If vi <b 

Proof. See above and Lemma|46l □ 

Lemma 35 (Transitivity of Higher-Rank subsumption I). If 01 <b 
02 and 02 <dsk V3, then ci <dsk V3. 

Proof. Follows from Lemmas [29| and [34] □ 

Lemma 36 (Transitivity of Higher-Rank subsumption H). If 
ci <dsk vi and V2 <b V3, then cri <d S k V3. 

Proof. Follows from Lemmas [29| and [34| □ 

F.3 Substitution 


Say prenex(v 4 ) = V 6 . p. By inversion, we know that vi —>• 
vi <d S k V3 —1 p. We also know that prenex (Wc.. V3 v±) = 
Vc, 6 . V3 —> p, so we can conclude with DSK_Inst. 

Case DSK_Inst: 


prenex(v 2 ) = Vc. P 2 
0 i[r/a][r 76 ] <^ sk p 2 
V{a},6.0i <dsk K2 


DSK_INST 


We note that prenex (Vc. U 2 ) = Vc, 6 . P 2 , so we can just apply 
DSK_Inst. 

Case SB_Inst: 


prenex(v 2) = Vc. P2 
0 i[r/a][r 76 ] < d * sk P2 
V{a}, 6.0i <dsk U2 
Similar reasoning to DSK_Inst. 


DSK_Inst 


:®S 

Lemma 31 (Monotypes are instantiations). If a <dsk t then 


Proof. Proof is by induction on a <dsk t. In each case the result 
holds directly by induction. ■ jig} 

Lemma 32 (DSK and prenex). For all v, we have v <dsk 
prenex (v). 


Although a more general substitution property is true for these sys¬ 
tems, in this development we need only substitute for generalized 
type variables. Therefore, we state these lemmas is more restrictive 

Lemma 37 (Substitution for System B). Assume that the domain 
of S is disjoint from the variables of r or the free type variables of 

1 . IfT fb e => o then r Ig e =>• S(a) 

2. IfT fg e w then T\ ge<^ S(v) 

Lemma 38 (Substitution for System SB). Assume that the domain 
of S is disjoint from the variables ofV or the free type variables of 

1. IfT la e 0 then Y hn, e => 5(0). 

2. IfT 4 e => v then Y (f b e =*> S(v). 

3. IfY If" e => a then Y [f n e ^ 5(c). 

4. IfY 4 e v then Y (f b e <^= S(v). 

5. IfY kb e<=p then Y h* e 5(p). 

F.4 Soundness of syntax-directed system 

Because of the differences between the syntax-directed and the 
declarative system, we need the following lemma about System B 
to prove the soundness of System SB. 

Lemma 39 (Prenex System B). IfY fg e <= p and prenex (0) = 
Va. p then T fg e A= 0. 


Proof. Proof is by induction on v. 


□ Proof. Case B_DAbs 


Lemma 33 (DSK Subsumption contains OL Subsumption). If 
Vi < 0 i v 2 then vi <dsk v 2 . 


Y, x-.v 1 lg e 4= V2 
T fg Xx. e ^ vi v 2 


B_DAbs 


Proof. Proof is by induction on the derivation. 
Case OL_B_ARefl: Trivial. 


In this case, because we are pushing in p, we have v 2 = p 2 . We 
also know that prenex (0) = Va. vi —y p 2 , so 0 must be of 
the form vi —yv 2 . 
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Write v 2 as Va\.fa. We also know that prenexfa) = 
Vai,a2-p2 where prenex(fa ) = V 02 ■ P2■ 

By induction, we have F, x:v\ ^ e 4= fa By (repeated) use 
of B_Skol, we have I\ x:v\ e <= Va. fa By B_DAbs, we 
can then conclude F ^ \x. e 4= vi —>• Va. fa, which is what 
we wanted to show. 

Case B_DLet 


r ^ ei => ai r, x:a 1 ^ e2 4= v 
T ^ let x = ei in e2 v 


B_DLet 


This case holds by induction. 

Case B_Skol This case is impossible, as the conclusion does not 
have the form 4>. 

Case B_Infer 


F.5 Completeness of syntax-directed system 
Lemma 40 (Context Generalization). Suppose F' <b T 
1, If T Ig, e =>■ cj) then there exists fa < b <f> such that L e =>■ 

fa- 

2- IfF hr b e =©- v then there exists v' <b v such that T' (f b e => 

3. If T lf b erl e => a then there exists o' <b o such that T' (f b n 

4. IfF tfb e 4= v and v <b v' then T 1 ' tf b e 4= v'. 

5. IfF kb e 4= p and p <b p' then T' 1^ e 4= p. 

Proof. Proof is by induction on derivations. 

Case SB_Abs: 


T tb e =t» cri cri <dsk V2 
T t e <^= v 2 


B_Infer 


Here we know that V2 is p. By inversion of o <dsk p, we have 
<7 = V{ai}, 61. fa where where prenex(fa) = Vc. p and 
P2[r/ai][r'/6x] < dsk P- 

However, as we also have prenex(fa) = Va. p, we can use the 
same information to conclude, o <d s k ©, and then use B_lNFER 
to show that F k e 4= 4>. 

□ 


Proof Soundness of System SB Lemma[7] states: 

1. If r la e s* (j) then P fe e =» fa 

2. If r 4 e v then F lg e v. 

3. If T e => ct then F lg e => a. 

4. If r lf b e 4=v thenT % e 4= v, 

5. If T ^ e 4= p then F e 4= p. 


Proof. Most of the cases of this lemma follow via straightforward 
induction. Cases SB_Spec, and SB_Var are similar to the cases 
for V_InstS and V_VAR, so are not shown. We include selected 


Case SB_Annot: 

Tht; v = Va.ct> T,a 
r f (e : v) =► V 

By induction we know that T, a lg. 
can conclude T If (e : u) => u. 
Case SB_Infer: 


e <t> 


SB_Annot 


4= (j>. By B_ANNOT, we 


r lfb e ^ Vi Vi <dsk 
no other rule matches 
F tb e 4= P2 


p2 


SB_lNFER 


By induction, we know that T ^ e => vi. We would like to 
show that T lb e 4= p2- This follows immediately by B_Infer. 
Case SB_DeepSkol 


prenex(v ) = Va.p 
a 0 uars(r) F U 
r 14 e v 


<= P 


SB_DeepSkol 


By induction, we have T lg e -t= p. Note that if prenex(v) = 
Va.p and v is of the form Va'.cj), then, by definition 
prenex (fa = Va". p and a = a', a". By the prenex 
lemma|39| we know that F k, e 4= fa We can then use multiple 
applications of rule B_Skol to conclude T lg e <= Va'. fa 


□ 


T, x-.t 4 e => 
r lib Ax. e =4> r - 
By induction, we know that T', 
Therefore, T' Ig, Ax. e =>■ r - 
i)'< b r-> v. 

Case SB_Int: 


SB_Abs 


lfb e => v’ for v' <b v. 
' and, by SB_Fun, r —k 


Trivial. 

Case SB_InstS: 


r lib 


Int 


SB_INT 


T lfb e => Va. (f> 
no other rule matches 


Fkbe^ far/a] 


SB_InstS 


By induction, we know that T (g b e =£- v' where v <b 
Va. <f>. By inversion, we know that v' must be of the form 
Va, b. fa where fa[r'/b] <b 4>. By SB_InstS, we can con¬ 
clude T lfb e =>- (fa[f/h])[r/a]. We also need to show 
that (</> , [rV6])[r/a] <b far/a], which follows by substitution 
(Lemma |22]>. 

Case SB_Var: 


x:V{a}. v € F 
F% b x^v(?M 


SB_Var 


We know that x\o € T, where o <b V{a}. v. So by inversion, 
o must be V{b}.v' such that u'[r'/6] <b v. Therefore, by 
substitution lemma|22| i/[r , /&][T/a] <b u[r/a]. As we know 
that the a are not free in v', we can rewrite the left hand side as: 
w'[r'[r/a]/6], and choose those types in the use of SB_Var. 

Case SB_App: 


r (f b ei e2 = 


SB_App 


By induction we have T' tg, ei =>• <j) such that (j> < b v\ —> v 2 . 
By inversion, this means that (j) must be of the form v( —k v 2 
where vi <b v( and v' 2 <b v 2 . 

By induction, we have T' (g b e 2 4= v[. So we can conclude by 
SB_App. 

Case SB_Let: 


T lfb" ei =4- cri T, x:cti (J, e2 = 


SB_Let 


By induction T' lfb" ei => cr( for o\ <b cri. By induction 
(again), T', x\o( (f b e 2 =r v 2 forv 2 <b v 2 . So we can conclude 
by SB_Let. 

Case SB_TApp: 


Fhr F 4 e =4> Va. v 
Tlfb e @r => u[r/a] 


SB_TAPP 
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By induction T' 4 e =£- v' where v' < b Va. v. By inversion, 
v' is of the form Va.vi where vi < b v. By substitution, 
«i[r/o]< b «[r/a]. 

Case SB_Annot: 


rhv w = Va-0 r, o tfb e <= <f> 

r 4 (e : v) => u 

By induction, we have r',a 4 e <= <j>, 
SB_Annot to conclude r' lf b e => v. 

Case SB_Phi: 


r^b e^cf, 

no other rule matches 


SB_Phi 


Holds directly by induction. 

Case SB_Gen: 

r 4 e => « s = M«) \ 

Tlf™ e =}■ V{a }.v 


SB_Gen 


By induction, we have r' 4 e v' for v' < b v. Let b = 
ftv(v')\vars(T). We wantto prove thatV{6}.w' < b V{a}.u. 
This holds by B_InstG, choosing r = a. 

Case SB_DAbs: 


r, x:vi 4 
r lib Ax. e < 


P2 

-f P2 


SB_DAbs 


Let T' <b T and vi —>• P 2 < b v' be arbitrary. By inversion, we 
know that v' is v[ —> v' 2 where v\ < b Vi and p 2 <b v 2 . 

By inversion, we know that v 2 must be of the form p 2 , as < b 
cannot introduce specified quantifiers. 

By induction, we know that T', x:v[ ^ p 2 . 

So we can conclude by SB_DAbs. 

Case SB_Infer: 


r 4 e =*• Vl V 1 <dsk p2 

no other rule matches 

-—- SB Infer 

r 4 e p 2 


Let T' <b r and p 2 <b p be arbitrary. By induction, we 
know that T' 4 e =>• v' for v' < b y 1. We want to show that 
v' <dsk (>' ■ This holds by lemmas|35l and [36| 

Case SB_DLet: 


nf b " 


ei =>■ in T, x\ai \^a e 2 <= p 2 
T la, let x = ei in e 2 <= p 2 


SB_DLet 


Let T' <b T and p 2 < b p be arbitrary. By induction, we 
have T' tf b ” e i =► for a '\ <b cr 1 . By induction (again), 
T', x:o\ 1^ e 2 <= p' ■ So we can conclude by SB_DLet. 

Case SB_DeepSkol 


prenex(v ) = Va.p 
a 0 mrs(T) T 4 
r lf b e <^= v 


<= P 


SB_DeepSkol 


Let T' <b T and v <b v' be arbitrary. Let prenex(v') = 
Va’. p'. By Lemma|26| we know that p < b p'. 

So by induction, T'Tib e <= p' 

Therefore, we can use SB_DeepSkol to conclude. 


□ 


Proof. Most cases of this lemma either follow by induction, or are 
analogous to the completeness lemma for System V. 


rt x 


B_Var 


Suppose o is for the form V{a}. v. Then we use a to instantiate 
the variables a. We know these a are not free in T by the 
Barendregt convention. It may be the case that generalization 
quantifies over more variables, i.e. a C a' = ftv(v)\vars(T), 
leading to a more general result type. However, that is permitted 
by the statement of the theorem. 

Case B_Abs 


r,x:rlb e =>u 
T Ij Xx. e => r v 


B_Abs 


The induction hypothesis gives us F,x:t (f b n e => V{a}.i>' 
where V{ a}. v' <4 v. Inverting 4" gives us T,x\t 4 e =£- 
v' and inverting <4 gives us v'[t/ a] < b v. We can then 
substitute and use SB_Abs to get T 4 Xx. e => r —> v'\r/a]. 
Generalizing, we get T lf b " A®, e =► V{a, o'}, r —i/[r/a] 
where the new variables a 1 come from generalizing t and the 
t'. We are done because (r —»• w')[r/a] <b t —>■ v and so 
V{a, a'}. t —*■ v' < b r —)■ u 
Case B_App 


T lb ei => v\ — y v 2 T lb e2 <= vi 

Fi i e 1 e 2 ^v 2 


B_App 


By induction we have T 4™ ei => o for some a < b vi -A v 2 . 
So by inversion cr = V{a}, b.v[ —> v 2 , where (v[ —>■ 
w 2 )[T/a][r'/ 6 ] < b wi -+ v 2 and in < b wi[r/a][r'/ 6 ] and 
i4[t/o][t'/&] <b v 2 . 

Also by inversion of lf b ra , we know that T 4 ei => Mb. v\ —> 
v'2 and that the a are not free in T or ei_. 

By substitution, we have T 4 ei =>\/b. (v[ —> v 2 )fr/W]: 

And by SB_InstS, we have T 4 e i =► —f 

v' 2 )[r/a][r'/b]. 

By induction we have T 4 e 2 <= v 'i and by lemma |53| we 
know that T 4 e 2 <= v[ [r/a] [r'/ 6 ]■ 

So we can conclude T 4 ei e 2 •<= v' 2 ^f/~a]ipf'/b\. 

Case B_Let 


r t ei ^ m r, x'.cii lb e 2 cr 
r lb let X = ei in e 2 ^ a 


B_Let 


The induction hypothesis gives us T 4" n ei =$■ cr'i with cr' < b 
cri. The induction hypothesis also gives us T, x:o 1 lf b ” e 2 =>• 
(72 with (72 <b (72. Use Lemma|53|to get T, x:o\ 4'" 62 => u 2 
where cr 2 <b cr 2 . 

Let (7 2 = V{6}.wwhere6 = ftv(y) \ vars(T). Inverting 
4" gives us F,x:a[ 4 e 2 => w. We then use SB_Let 
to get T 4 let ^ = ei in e 2 =>■ w. Generalizing gives us 
T 4" let ® = ei in e2 => v - 
Transitivity of < b (Lemma[24) gives us V{6}. v <hmv 01 • 
Case B_Int 


Trivial. 

Case B_TApp 


r ^ 


Int 


B_lNT 


Proof of Completeness of System SB Lemma[8]states: 

1. If r lb e =>cr then r 4" e ^ o' where o' < b o. 

2. If T lb e <t= w then f 4 e <= r, 


T lb e @t =>• v[t/o\ 

The induction hypothesis (after inverting 4'”) gives us T 4 
e Va. v', where b = ftv(\/a. v') \ vars(T) and u'[r/6] < b 
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v. Applying SB_TApp gives us T 4 e @r => v'[T/a\, 
and SB_Gen gives us T g en e @r => V{c}.i/[r/a] 
where c = ftv(v'[r/a\) \ vars(T). We want to show that 
V{c}. v'[r/a] <b v[t/o\, which follows when there is some 
t\ such that v' [t /a][r'/c] <b v[t/o\. 

This is equivalent to exchanging the substiution, i.e. finding a 
t' such that v' [r' / c] [r / o] 4 u [r / a]. 

By Substitution (Lemma |22|>, we have t/[r/&][r/a] <b 
v[t/ a]. We also know that the 6 are a subset of the c. So we 
can choose r' to be r for the b, and the remaining c elsewhere, 
and we are done. 

Case B_Annot 


r l u 


r,¥%e 


r ^ (e : v) = 


B_Annot 


By induction, we have T, a g e <= cj>. We can conclude by 
SB_Annot. 

Case B_Gen 


r t e => <7 a 0 uars(r) 


B_Gen 


The induction hypothesis gives us T g"' e => cr' where cr' < b 
cr. We know cr' <b V{a}. a. In other words, if cr' = V{ 6 }. Vi 
and cr = V{c}. V2, we have some r such that vi\r/b\ = V2. 
By the definition of <b we can use these same r to show that 
cr' < b V{a, c}.v 2 . 

Case B_Sub 


r t e (71 (71 <b (72 

r e =>(72 


B_Sub 


The induction hypothesis gives us T g en e => cr' where 
a' <b cri. By transitivity of <b , we are done. 

Case B_DAbs 


T, x:vi ^ e<=v 2 
r\ i \x.e^v 1 ^v 2 


B_DAbs 


By induction, we have that T, x:v\ ij b e <= V2- 
By inversion, we have prenex(v2) = Va. p and T, x:vi 


e<=p. 

Therefore by SB_DAbs, we 
p, and by SB_DeepSkol, v 

Case B_DLet 

r ^ ei => (7i r, 

r fh let X = ei i 


mconclude T lf b Ax. e <= vi 
know T ij b Ax. e <t= Wi —> 


B_DLet 


By induction we have T, x:a i if b e 2 <= v. Also by induction, 
there is some cr' <b cri, such that T i| b n e => cr'. By context 
generalization, we know that T, i| b e 2 <= v. So we can 
use SB_DLet to conclude. 

Case B_Infer 


r tb e => ( 7 l ( 71 <dsk V2 

V\- b e^V2 


B_Infer 


In this case, we know that cri <dsk t' 2 . We would like to show 
that T g <a *= v 2 . Suppose prenex(v 2 ) = Va. p, by rule 
SB_DeepSkol, it suffices to show T g e <= p. 

Suppose cri is V{ft}. vi. By inversion of a 1 <dsk ( ' 2 , we know 
that vi [r'/b\ < ds k p. 

By induction, there is some a' <b cri, such that T g n e => cr'. 
By inversion of g™ we know that cr' is of the form V{a}. v' 
and that T g e => v'. 

By inversion of cr' <b cri, we know that i/[r/a] < b vi. By 
substitution, this means v , [T/o'][r , / 6 ] <b vi [r'/fe]. By the 


Barendregt convention, the b can appear in the r but not in 
v'. So we can rewrite this substitution as /b\/li\. We 

can then substitute (as the a were generalized) T g e => 
v’[f[T'{b]/a]. 

By transitivity (Lemma|35| we know that v' [r [t'/ b] / a] <d s k p. 
So we can conclude T ^ e <t= p using SB_Infer. 

Case B_Skol 


rib e<S=K a ^ t>flra(T) 
T fb e <t= Va. v 


B_Skol 


By induction, we have T g e <= v. We would like to 
conclude T g e <= Va. v. By inversion, we have T ^ 
e <= p where prenex(v) = Va. p. However, this means that 
prenex(\/a. v) = Va, a. p. Therefore, we can conclude using 
SB_DeepSkol. 


□ 


Unlike System V, we have not shown that the algorithm deter¬ 
mined by System SB computes principal types. We believe that all 
of the complexities of that proof are already present in the corre¬ 
sponding proofs about System V and the extensive proofs for the 
bidirectional type system of GHC 126 1. 
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OL_B_ARefl 


V3 <ol 
Vl -A 


OL_B_AFun 


<Mt/o] <oi <j >2 6 0 ftv(\/a. <j> i) 

VO. 01 <„1 V6. 02 


OL_B_AlNSTS 


Synthesis rules for System B 


x:aer 

r^x^o- 


OL_B_Var 


Figure 14. Subsumption in the Odersky-Laufer type system 


T,x:r^e^v 

Th b Xx.e^r^v 


OL_B_Abs 


G. Higher-rank systems: OL variant 

This section concerns the properties of a higher-rank type system 
that does not include deep skolemization and provides an alterna¬ 
tive treatment of scoped type variables. 

We present this system mainly for comparison with Dun- 
field/Krishnaswami (9) (see below). However, it also shows that 
the deep-skolemization relation is not an essential component of 
our type system. Instead of <dsk, it uses the Odersky-Laufer sub- 
smption relation shown in Figure [14] 

The only difference between this system and the DSK version 
of System B, is the use of this relation in the B_lNFER rule and the 
treatment of scoped type variables in the B_Annot and B_Skol 
rules. See Figure [15] The syntax-directed version of the system is 
in Figure [l6| It differs from System SB in that it again uses the < 0 | 
relation, introduces scoped type variables at SB_Skol and does 
not do deep-skolemization in the checking rule for polytypes. 

A note on scoped type variables The alternative mechanism for 
scoped type variables leads to some “strange” binding behavior. In 
particular, if y has the following type in the context 
y : (Vo. o-u)-t Int 

then the expression 

V (Ax. (x : a)) 

would be well typed, even though the specification of y’s type could 
be very far from this application. Likewise, we only introduce top- 
level variables into scope. In particular, 

(Ay. Ax. (x : a) : Int -A Vo. a -t a) 
would be well-typed if we introduced scoped type variables in rule 
B_Skol, but is rejected by system B. 

G.l Properties of OL subsumption 

Lemma 41 (Substitution). Ifvi < 0 i v 2 then S(v\) < 0 i S(v 2). 


Proof. Vytiniotis et al.. Lemma 2.1 (|26)) □ 

Lemma 42 (Reflexivity for < 0 i ). For all v, v < 0 | v. 

Proof. Vytiniotis et al.. Lemma 2.2 (|26)) □ 

Lemma 43 (Transitivity for < 0 | ). If vi < 0 i Vi and v 2 < 0 i V3, 
then vi <oi V3. 

Proof. Vytiniotis et al.. Lemma 2.3 (|26)) jljjf 

Lemma 44 (Single skol admissible). If V\ < 0 i v 2 then v\ < 0 i 
Vc. V2 (when c is not free in vi). 

Proof. Proof is by induction on Vi < 0 | v 2 . □ 


T ^ lets = ei in e 2 = 


T ^ n => Int 

Thr r^e^Vo.' 
r ^ e @r => v[t/ a] 

rhu rt e<=v 


T\- b (e:v) = 


OL_B_Annot 


^( r ) 


rte^V{o}.a 
r lg e => 01 ffi <b 02 


T, x:vi ^ e <=v 2 
r t Ax. e <= vi —v v 2 


T (5 ei => in r, x:oi ^ e 2 < 


F,ah b e^v a g vars( F) 

rte^Vo.t) 


r e => vi vi <01 v 2 


Figure 15. Declarative specification of System OL-B 
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Lemma 45 (Monotypes are instantiations). Ifv < 0 i rthenv <b r. 


\?kb e=>4>\ 

r, x:r f b e =* v 
r (jb Ax. e => r —> v 


OL_SB_ABS 


r ^ 


lot 


OL_SB_lNT 


Proof. Proof is by induction on v < 0 i T. In each case the result 
holds directly hy induction. □ 

Lemma 46 (Subsumption contains instantiation). Ifvi <b V2 then 
v\ <oI v 2 . 


r f b e => Va. cj) 

no other rule matches 

r f b e =>• v I 


OL_SB_InstS 


x:V{a}.u er 
r if b x ^ v[t/s] 


OL_SB_Var 


r lib ei => W1 -A V 2 
r tg ei e 2 


OL_SB_App 


Proof. Proof is by induction. 


Case B_Refl: Trivial 
CaseB_FUN: By induction. 
Case B_InstS: 


0 i[t/ 6] <b 02 
Va, b. 0i <b Va. 02 


B_InstS 


By induction we know that 0 i [r/6] < 0 | 02. We can rewrite this 
as 0i[a/a][r/6] < 0 i 02, and conclude by DSK_Inst. 


T ei => <7i T, x:<7i e2 => V2 
T f b let x = ei in e2 =>■ t>2 

T h r T f b e =* Va. v 


v[r/a] 


OL_SB_TApp 


ri-w r f b ( 
r fb (e : v) = 


OL_SB_Annot 


I r fb ’ 1 e => <7 | 


ffi 


Lemma 47 (Transitivity of Higher-Rank subsumption I). Ifvi<b 
V 2 and V 2 < 0 i V3, then v% < 0 i V 3 . 

Proof. Follows from Lemmas [43] and [46] □ 

Lemma 48 (Transitivity of Higher-Rank subsumption n). If 
vi < 0 i V2 and V2 <b V3, then vi < 0 i V3. 


Proof. Follows from Lemmas [43] and[46) Q 

G.2 Substitution 


r fb e =» « a = ftujv) \ vars(T) 

rf* e =>• V{o}. v 

r lib e 0] 


OL_SB_Gen 


r, x-.Vi fb e •<= v 2 
r 1^ Ax. e <= vi V 2 


OL_SB_DAbs 


Lemma 49 (Substitution for System B). Assume that the domain 
of S is disjoint from the variables of r or the free type variables of 


1. IfT f e =*• o then r f e =*• 5(a) 

2. If r f e w then r f e -t= S{v) 

Lemma 50 (Substitution for System SB). Assume that the domain 
of S is disjoint from the variables of r or the free type variables of 


r fb" ei => <j 1 r, x:<7i lib e2 4= 02 

r fb let x = ei in e2 <= 02 


OL_SB_DLet 


r fb e => Ui Vi <01 02 

no other rule matches 

r lib e <= 02 


OL_SB_Infer 


r fb e 


r, o' lib e<= <t> a<£vars(T) 
r f b e 4= Va. 0 


OL_SB_Skol 


Figure 16. Syntax-directed specification of System OL-SB 


1. IfT la e =*• 0 then V bn, e => 5(0). 

2. IfT f b e =* v then T f b e =» S(v). 

3. IfT f b e " e => a then T e => S(o). 

4. IfT f b e <= v then r f b e <t= S(v). 

5. IfT 1^ e 0 then T e 5(0). 

G.3 Other properties 

Lemma 51 (Monotypes are uninformative). If T f e <= t then 

r^e^r. 


Proof. This follows because of the four checking rules, the first 
two have identical monotype versions, the third doesn’t apply to 
monotypes and the last follows by B_Sub and the fact that r is an 
instantiation of <7 (lemma ED- □ 
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G.4 Soundness of System SB 
Lemma 52 (Soundness of System SB). 

1. IfT ^ e =» 0 then T (5 e =k cj>. 

2. IfT \j b e => v then T lg e => v. 

3. IfT If* e => a then T lg e => cr. 

4. IfT \^ b e <= v thenT ^ e <= v. 

5. IfT ^ e <= 0 then T lg e <= <j>. 


Proof. Most of the cases of this lemma follow via straightforward 
induction. Cases SB_Spec, and SB_Var are similar to the cases 
for V_InstS and V_Var. 


Case SB_Infer: 

r lf b e ^ Wi vi < 0 i 02 

no other rule matches 

r lib e ^ 02 

By induction, we know that T 1 lg e =£• 
r ^ e <= 02 by B_Infer. 

Case SB_Skol 


OL_SB_Infer 
vi . We can show that 


r, a Ijb e <= </> atvars{T) 
T |b e Vo. 0 


OL_SB_Skol 


By induction, we have T lg e <= p. We can immediately use 
rule B_Skol to conclude. 


□ 


G.5 Completeness of SB 

Generalizing and specializing syntax-directed derivations 
Lemma 53 (Context Generalization). Suppose T' < b T 
1- If r lib e => 0 then there exists <j>' < b 0 such that T' lib e => 

2. IfT (f b e v then there exists v' < b v such that r' (j b e => 

3. If T \^ b n e => a then there exists o' < b o such that T' lf b " 

4. IfT Ifb e <= v and v < b v' then r' (f b e <= v'. 

5. IfT lib e <= 0 and 0 < b 0 ( then T' lib e <= 0. 

Proof. Proof is by induction on derivations. 


that (0'[r'/6])[r/a] < b 0[r/a], which follows by substitution 
(Lemma |22]>. 

Case SB_Var: 


z:V{o}.t;er 
r lf b x v[r/d] 


OL_SB_Var 


We know that x\o € T, where o < b V{a}. v. So by inversion, 
a must be V{b}.v' such that w'[r'/6] < b v. Therefore, by 
lemma [22] v'\r' /b]\r/d\ < b w[f/a]. As we know that the 
a are not free in v', we can rewrite the left hand side as: 
/a\/b\, and choose those types in the use of SB_Var. 

Case SB_App: 


L i>2 nj b e 2 <= Vi 
ei &2 => V2 


OL_SB_App 


By induction we have T' 1^ ei => 0 such that 0 < b vi —F v 2 . 
By inversion, this means that 0 must be of the form v\ —> v 2 
where v\ < b v\ and v 2 < b v 2 . 

By induction, we have T' (f b e2 <= v[ \f/b\. So we can 
conclude by SB_App. 

Case SB_Let: 


r If 1 ei =k <71 r, x:oi l| b e 2 v 2 
T lf b let x = eiin e 2 => v 2 


OL_SB_Let 


By induction T' ei => o\ for a\ < b cri. By induction 
(again), T', x\o[ (f b e2 => v 2 for v 2 < b v 2 . So we can conclude 
by SB_Let. 

Case SB_TApp: 


r h r r lfb e =» Va. v 
r lf b e @T =* v[r/a] 


OL_SB_TApp 


By induction T' (f b e => v' where v' < b Va. v. By inversion, 
v' is of the form Va. V\ where vi < b v. By substitution, 
vi[r/a] < b v[t/o]. 

Case SB_Annot: 


Th« r4e<=u 
r lf b (e : v) => v 


Holds directly by induction. 
Case SB_Phi: 


OL_SB_Annot 


Case SB_Abs: 

T, x:t lfb e •=#■ 
r lib Ax. e =4> r 
By induction, we know that 
Therefore, T' l^g Ax. e => ■ 
v' <b t —¥ v. 

Case SB_Int: 


OL_SB_Abs 

lfb e => v' for v' <b v. 
>' and, by SB_Fun, r —> 




Trivial. 

Case SB_InstS: 


Int 


OL_SB_lNT 


r 4 e Va. 0 
no other rule matches 
r lib e ^ 0[r/a] 


OL_SB_InstS 


By induction, we know that T (f b e => v' where v' < b 
Va. 0. By inversion, we know that v' must be of the form 
Va, b. 0' where 0 '[t'/&] < b 0. By SB_InstS, we can con¬ 
clude T l|b e => (0 , [r'/t])[r/a']. We also need to show 


Tl* e=>0 
no other rule matches 


T lf b e => 0 


OL_SB_Phi 


Holds directly by induction. 
Case SB_Gen: 


r lb e =► v d — fiv(v) \ vars(T) 
Tlfb 6 ” e=>V{a}.w 


OL_SB_Gen 


By induction, we have T' lg b e => v for v' < b v. Let b m 
ftv(v')\vars(T). We want to prove that V{6}. w' < b V{a}.w. 
This holds by definition. 

Case SB_DAbs: 


T, x:v! lj b e -$= v 2 
T 1^ Ax. e <= vi -y v 2 


OL_SB_DAbs 


Let T' < b T and v\ -A v 2 < b v be arbitrary. By inversion, 
we know that v' is v[ —>■ v 2 where v\ < b vj and v 2 < b v 2 . 
By induction, we know that T', x:v[ lfb e <= v 2 . So we can 
conclude by SB_DAbs. 
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Case SB_Infer: 


rif b e^wi vi < 0 i (j>2 

no other rule matches 


r lib e 4= <f>2 


OL_SB_Infer 


Let T' <b r and 0 2 < b <t>' be arbitrary. By induction, we 
know that T' e => v' for v' <b v i • We want to show that 
v' < 0 i <p'. This holds by lemmas |47] and [48| 

Case SB_DLet: 


Also by inversion, we know that T f b ei =4- V5. v\ —¥ v' 2 and 
that the a are not free in T or ei. 

By substitution, we have T f b ei =3- V6. (v[ —> v 2 )f r /®1 
And by SB_InstS, we have T f b ei =t- (v[ -A 

v' 2 )[T/a][r'/b\. 

By induction we have T f b e2 <= v\ and by lemma |53[ we 
know that F f b e 2 <= ui[r/a][r'/ 6]. 

So we can conclude T f b ei e 2 •<= v' 2 [r/ a] [r'/ 6], 

Case B_Let 


T ff n ei =*- o i T, x:o i lib e2 <= cj>2 

T li b let x = ei in e 2 <= (j> 2 


OL_SB_DLet 


T, x:<Ti Ig e 2 => cr 
ei in e 2 =t- cr 


OL_B_Let 


Let T' < b r and 02 < b </> / be arbitrary. By induction, we 
have T' ff n ei =>■ o\ for o\ < b eri. By induction (again), 
T', x:o[ f b e 2 <= < t>. So we can conclude by SB_DLet. 

Case SB_Skol: 


T ,ak,e^<f> a?vars{F) 

T lf b e<=Va.<f> 


OL_SB_Skol 


Let F' < b T be arbitrary. Result holds by directly by induction 
and SB_Skol. 


□ 


Completeness theorem 

Lemma 54 (Completeness of System SB). 

1. IfF ^ e => o then T ff n e ^ o' where o' < b cr. 

2. IfF ^ e v then V f b e v. 


Proof. Most cases of this lemma either follow by induction, or are 
analogous to the completeness lemma for System V. We discuss the 
most novel cases are B_App, B_Annot, plus the checking rules. 


Case B_Var 


OL_B_Var 


Let o he V{ a}. v. We can use the types a to instantiate the 
variables a. We know these a are not free in T by the Barendregt 
convention. It may be the case that generalization quantifies 
over more variables, i.e. o C nl = ftv(v) \ vars(T), leading 
to a more general result type. However, that is permitted by the 
statement of the theorem. 

Case B_Abs 


T, x:t lb e =>■ v 
T lb A x.e^T^v 


OL_B_Abs 


The induction hypothesis gives us F,x:r iff" e =>■ V{a}. v 
where V{a}. v' < b v. Inverting Iff" gives us T, x:r lf b e => 
v' and inverting < b gives us i/ff/a] < b v. We can then 
substitute and use SB_Abs to get T 1^ \x. e => r — > v'[t/ a\. 
Generalizing, we get T Ifb" As. e => V{o, o'}, r -A v'[r/a] 
where the new variables a' come from generalizing r and the 
r. We are done because (r —>■ i/)[r/a] < b r —>■ v and so 
V{a,o'}.T->-w' < b T-Ar; 

Case B_App 


T 1^ ei =► vi —> V2 T 1^ e 2 4= vi 

r lb ei e 2 V2 


OL_B_APP 


By induction we have T iff" ei =t- cr for some o < b Wi —F v 2 . 
So by inversion o m. V{o}, b. v[ —> v 2 , where (v[ -A 
v' 2 )[T/o][r'/6] < b vi -A V2 and wi < b v'^fr/~a]^f'/ b] and 
w^[r/a][r'/6] < b v 2 . 


The induction hypothesis gives us T iff" ei A- o[ with of < b 
<7i. The induction hypothesis also gives us T, x:oi Iff" e 2 A 
02 with <72 < b cr 2 . Use Lemma [53|to get T, x:o\ iff" e 2 A o 2 
where o 2 <b o' 2 . 

Let <72 = V{6}.w where & = ftv(v) \ vars{F). Inverting 
Iff" gives us T, x\o'\ tf b e 2 A v. We then use SB_Let 
to get T Ifb l et x = ei in e 2 A v. Generalizing gives us 
r Iff" let x = ei in e 2 A Vffl. v. 

Transitivity of < b (Lemma|24| gives us V{6}. v <hmv cr 2 . 

Case B_Int 


r f n => Int 


OL_B_Int 


Trivial. 

Case B_TApp 


r | e -> Vo. V 
@r^v[r/a] 


OL_B_TAPP 


The induction hypothesis (after inverting Iff") gives us T f b 
e Va. v' , where b = ftvfia. v') \ vars(T ) and u'[r/6] < b 
v. Applying SB_TApp gives us T f b e @r =A v'[t /a], 
and SB_Gen gives us V ff n e @r =4> V{c}. v'[r/a] 
where c = ftv(v'[r/a]) \ vars( T). We want to show that 
V{c}. t»'[r/o] < b v[t/o\, which follows when there is some 
r', such that ^'[r/oj^'/c] < b v[r/a]. 

This is equivalent to exchanging the substiution, i.e. finding a 
t 1 such that u'[t7c][t/o] < b u[r/o]. 

By Substitution (Lemma ]22|>, we have v'[r/b] [t/ a] < b 
v[t/ a]. We also know that the b are a subset of the c. So we 
can choose t' to be r for the b, and the remaining c elsewhere, 
and we are done. 

Case B_Annot 

T\-v Fk e^v 


Fk b {e-.v)^v 


OL_B_Annot 


The induction hypothesis gives us T f e 4= v, so the result 
immediately follows. 

Case B_Gen 


TljeAa a ^ vars(F) 
T f e A V{a}. <7 


OL_B_Gen 


The induction hypothesis gives us T ff" e => o' where o' < b 
cr. We know o' < b V{a}. <7. In other words, if o' = V{6}. ui 
and <7 = V{c}. v 2 , we have some r such that Vi [r/b] = u 2 . 
By the definition of < b we can use these same r to show that 
o' < b V{o, c}.v 2 . 

Case B_Sub 


T f e => <7l <7l <b 02 

F f e => cr 2 


OL_B_Sub 


The induction hypothesis gives us T ff" &=> o' where 
o' < b <71. By transitivity of < b , we are done. 
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Case B_DAbs 


T, x-.vx ft e <= v 2 
r^\x.e^v 1 ^v 2 


OL_B_DAbs 


By induction, we have that T, x:vx lf b 
SB_DAbs, we can conclude F [f b \x. 
Case B_DLet 

r lb ei =► CTi r, x:ai ^ e 2 <= 
r ^ let x = ei in e 2 4= v 


OL_B_DLet 


By induction we have T, x:ai lf b e 2 <= v. Also by induction, 
there is some a 1 < b <J \, such that T lf b n e => a'. By context 
generalization, we know that P. x:a[ e 2 <= v. So we can 
use SB_DLet to conclude. 

Case B_Skol 


P,«t^« a * uars(r) 
P ^ e<=Va.v 


OL_B_Skol 


By induction, we have T, o lf b e <= v. We can conclude 
using SB_Skol. (Actually, first inverting and then potentially 
applying SB_Skol multiple times). 

Case B_Infer 


- ——-—- OL B Infer 

r fh e 4= v 2 - 

By induction, there is some cr' < b Vi, such that P lf b n e =$■ cr'. 
By inversion of tf b " we know that cr' is of the form V{a}. v 
and that r lf b e v', where a do not appear in e and P. 

By inversion of <b, we know that i/[r/a] < b v-,. By substi¬ 
tution, we know that P £e =>• v'[r/a]. 

By transitivity (Lemma |47) we know that i/[r/a] < 0 | v 2 . So 
we can conclude using SB_Infer. 

□ 


actually does, but because we have the instantiation relation, our 
declarative system need not make this constraint. 

Lemma 56. If V \- DK Vi ° e =>=> v 2 then there exists some v[ 
such that vi <b v[ —> v 2 and T \~dk e <= v[. 

Proof. Proof is by induction on the judgement. It requires an ob¬ 
servation about our instantiation judgement that if vi < b v[ v 2 
and v\ is Mb. p, then we must have instantiated all of the 6 in the 
judgment. In otherwords, that p[r/6] = v\ —>■ v 2 . 

□ 

Now let r \~dk e =£> v, T hnK e <= v be the judgements 
shown in Figure 4 of their paper. We can also argue that System B 
can typecheck the same terms. 

Lemma 57. 

L IfV \~dk e v then V e <= v. 

2. IfV\-DK e => w then T fb e => w. 

Proof. Proof is by induction on derivations. Most cases have direct 
analogues in System B. Note that technically we replace their unit 
type with int. They view the checking rule for the unit value as 
primitive and add a synthesis rule for convenience. Our system does 
not have a checking rule for constants, but can derive one from the 
synthesis rule and B_Sub. 

The only other case that requires additional reasoning is the 
convenience rule for inferring the types of functions. We need to 
use lemma|5T|to convert a checking judgement for monotypes into 
a synthesis judgement. □ 


G.6 Comparison with Dunfield / Krishnaswami 

The presence of the non-deep-skolemization System B, makes it 
easy for us to compare our type system with the system designed 
by Dunfield and Krishnaswami. (We refer to this system as DK in 
the following.) In particular, we can show that our system subsumes 
the DK system. 

Suppose r I ~dk vx f v 2 is the subtyping relation from the DK 
paper. Figure 1. 

Lemma 55 (Higher-rank subsumption contains DK subtyping). If 

r P dk Vx < v 2 then vx < 0 i v 2 . 

Proof. But induction on the DK subtyping judgement. 

Case DeclsJVar Immediate from DSK_Refl. 

Case DeclsJUnit Immediate from DSK_Refl. 

Case Decl^— > Directly via induction and DSK_Fun. 

Case DecK VL By induction and DSK_Inst. 

Case DecK VR By induction and DSK_Inst. 

□ 


The DK system includes an application judgement, written 
r hi jk vx o e =?=>- v 2 , which means "applying a function of type 
Vx to e synthesizes type v 2 ". 

Our declarative system does not need this judgement because 
we allow implicit instantiation for specified polytypes. In our sys¬ 
tem, the rule B_Sub allows instantiation at any point in the judge¬ 
ment. However, in the DK system, instantiation is restricted to be 
immediately before an application or when synthesis mode and 
checking mode meet (via subtyping). This is what our algorithm 
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